Week 3.5 Facilitator Hand-Outs

WATCH BILL BUILDER, Phase 1 whiteboard plan. Twenty minutes. No AI yet.

Write all five sections on paper or whiteboard before you touch your editor.

1. INPUTS
   - Section / unit name
   - Watch type (Duty NCO, Fire Watch, Quarterdeck, Phone Watch, Barracks Duty, SDO, OOD, or custom)
   - Start date (YYYY-MM-DD)
   - Number of days (1 to 365)
   - Roster: free-text list, one Marine per line
   - Skip suffix on roster lines: "- LV" or "- TAD" or "- APPT" means unavailable

2. RULES
   - Rotate through available Marines in order
   - Skip anyone with a skip suffix
   - Fairness check: spread between most-watches and fewest-watches should be 0 or 1 across the period
   - Weekends shown but not treated differently

3. OUTPUTS
   - On-screen table: Date, Day of Week, Watchstander
   - Fairness summary: per-Marine counts, total slots, spread number
   - Skipped list: who was excluded and why
   - Email body in a textarea with Copy button, plain-text monospace table
   - Print: clean, no header chrome, fits US Letter

4. EDGE CASES
   - Empty roster: inline error, do not generate
   - Everyone marked unavailable: inline error
   - Single available Marine over 14 days: that Marine on every day, surface in fairness summary
   - Invalid date: inline error
   - Days < 1 or > 365: inline error

5. OUT OF SCOPE (Capability Gap Map candidates)
   - Pulling roster from MOL automatically
   - Reading leave block from system of record
   - Notifying watchstanders by email
   - Persisting bills across sessions for multiple sections

Build me a single-file static HTML tool called Watch Bill Builder. Constraints:

- One .html file. Inline CSS. Inline JavaScript. No external scripts, no external fonts, no external stylesheets, no CDN. It must work 100% offline after page load.
- Mobile responsive. Prints clean to US Letter.
- Has an UNCLASSIFIED banner at top and bottom.

Inputs:
- Section name (text)
- Watch type (dropdown: Duty NCO, Fire Watch, Quarterdeck, Phone Watch, Barracks Duty, SDO, OOD, Custom)
- Custom watch name (text, shown only when Custom is selected)
- Start date (date)
- Number of days (number, 1 to 365)
- Roster textarea (one name per line; suffix "- LV", "- TAD", or "- APPT" means skip)

Logic:
- Rotate available Marines in order
- Skip anyone with a skip suffix
- Build a date range starting at start date
- Fairness check: report per-Marine watch counts and the spread (max minus min)

Outputs:
- Table of Date / Day / Watchstander
- Fairness summary section with per-Marine counts and spread number
- Skipped list showing who was excluded and the reason
- Email-pasteable plain-text table in a textarea with a Copy button
- Subject line auto-built from inputs

Errors handled inline (not silent):
- Empty section name
- Empty roster
- All Marines marked unavailable
- Invalid date
- Days less than 1 or more than 365

Give me the full HTML in one response. Do not split into multiple files. Do not use any framework.

WATCH BILL BUILDER, Phase 3 verification. Run all six tests in order.

[ ] 1. EMPTY ROSTER
    Clear the roster textarea. Click Generate.
    Expected: inline error, "Roster is empty" or similar.
    Fail mode: silent no-op (no error appears).

[ ] 2. ALL ON LEAVE
    Roster: every line ends with "- LV".
    Expected: inline error, "No available Marines" or similar.

[ ] 3. ZERO DAYS
    Set Number of Days to 0. Click Generate.
    Expected: inline error.

[ ] 4. OVER-MAX DAYS
    Set Number of Days to 400. Click Generate.
    Expected: inline error capping at 365.

[ ] 5. SINGLE MARINE, 14 DAYS
    Roster: one available Marine. Days: 14.
    Expected: that Marine on every day, fairness summary reports spread = 0 across 1 Marine (or surfaces the imbalance).
    Fail mode: silent or hidden imbalance.

[ ] 6. COPY TO OUTLOOK
    Generate a bill. Click Copy Email Body. Open Outlook. Paste.
    Expected: monospace table survives, columns align, no broken characters.
    Fail mode: lost spacing, weird characters, or copy did nothing.

[ ] 7. PRINT (bonus)
    Ctrl+P or Cmd+P. Preview.
    Expected: input form is hidden, bill table is the whole page, fits US Letter for 14 days.

In the Watch Bill Builder you generated, when I [describe the test you ran, e.g., "leave the roster empty and click Generate"], [describe what happened, e.g., "nothing happens and no error appears"].

I want it to instead [describe the desired behavior, e.g., "show an inline error below the form that says exactly 'Roster is empty. Add at least one Marine.'"].

Show me only the JavaScript change. Do not regenerate the whole file. Do not change anything else.

DEPLOY YOUR WATCH BILL TO A PUBLIC URL, 5 steps.

1. Go to github.com. Sign in. Click the "+" in the top right. Pick "New repository."
   - Name: watch-bill (or whatever you want)
   - Visibility: Public
   - Click "Create repository."

2. On the new empty repo page, click "uploading an existing file" (in the quick setup section).
   - Drag your watch-bill.html into the browser.
   - Click "Commit changes."

3. In the repo, click Settings (top menu).
   - In the left sidebar, click Pages.
   - Under "Source," pick "Deploy from a branch."
   - Branch: main, folder: / (root).
   - Click Save.

4. Wait 60 to 90 seconds. GitHub builds the site.
   - URL is: https://<your-username>.github.io/<repo-name>/watch-bill.html

5. Open the URL in your browser. Open it on your phone.
   - If both load, you just deployed.
   - Share the URL with the Marine next to you. Watch them open it.

If github.io is blocked from your duty workstation, see the static hosting cheat sheet for Tier 2 alternates (Cloudflare Pages, GitLab Pages). The skill is identical across hosts.

Build me a single-file static HTML TEEP tool (Training, Exercise, and Employment Plan).

- One .html file. Inline CSS, inline JS, no external dependencies. 100% offline after page load.
- UNCLASSIFIED banner top and bottom.
- Mobile responsive.

Stores training events with these fields:
- Name (text)
- Type (dropdown: Field, Live Fire, Range, CBT, Garrison, Inspection, Coordination, Annual Training, School, Deployment)
- Start date (date)
- End date (date)
- Status (Planned / Confirmed / Executed / Cancelled)
- Resources or notes (textarea)
- T&R references (text, optional)

UI:
- Toolbar with unit name, "Add Event" button
- Table of events sorted by start date
- Each row shows the fields above plus Edit and Delete buttons

Persistence:
- Use localStorage so events survive a page reload
- Store under key "edd-teep-v1"

Give me the full HTML in one response.

The TEEP tool works but I cannot brief from it. Add the following to the existing file:

1. SUMMARY CARDS at the top of the page:
   - Total events
   - Count Planned
   - Count Confirmed
   - Count Executed
   - Count Cancelled
   Each card has a label, a number, and a color cue. Use color to differentiate status at a glance.

2. T-X DAYS INDICATOR next to each event row.
   - If the event is upcoming, show "T-Nd" where N is days until start
   - "TODAY" if N = 0
   - "tomorrow" if N = 1
   - "Nd ago" if past
   - "complete" if status is Executed
   - "cancelled" if status is Cancelled

3. HIGHLIGHT CONFIRMATION GAPS.
   - Any event with status "Planned" that is inside 14 days should visually stand out (different color or weight).
   - Tooltip or label: "Confirmation gap, push for confirmation."

Show me only the changes to the existing file, not the whole rebuild. Where does each addition go (which function, which CSS rule).

Add color coding to the status column.

- Planned: blue
- Confirmed: green
- Executed: gray
- Cancelled: red

Make the colors WCAG AA contrast against the background. Show me only the changes I need to apply to the file I already have.

The styling does not apply. I tried setting the style inline on the cell with element.style.background and nothing changes. The browser shows the cell still white. I think a CSS class on the parent is winning the specificity battle.

Give me a CSS-class-based approach instead:
- One CSS class per status: .status-Planned, .status-Confirmed, .status-Executed, .status-Cancelled
- Define each class in the <style> block with background, color, and any other treatment needed for WCAG AA contrast
- In the JS that renders each row, set element.className = "status-pill status-" + event.status

Show me:
1. The <style> additions
2. The JS line that sets the class (and which function it goes in)

Do not regenerate the whole file. Only the changes.

Add a button labeled "Generate S-3 Brief" to the TEEP tool. When clicked, it produces a plain-text briefing block in a read-only textarea. Format:

Line 1: "S-3 TRAINING BRIEF"
Line 2: "Unit: [unit name]"
Line 3: "As of: [today's date in DD MMM YY format] ([fiscal year and quarter, e.g., FY26 Q3])"
(blank line)
STATUS SUMMARY
[one line: "Total TEEP events: N. Planned: X. Confirmed: Y. Executed: Z. Cancelled: W."]
(blank line)
NEXT 14 DAYS (count events)
[one line per event in next 14 days: "T-Nd  DD MMM YY  Event name (Type, Status)"]
[indent and show "Resources: ..." line under any event that has resources]
(blank line)
NEXT 15 TO 30 DAYS (count events)
[same format]
(blank line)
CONFIRMATION GAPS
[any Planned events inside 14 days, listed one per line with "- Event name (T-Nd)"]
(blank line)
REQUEST
[if there are confirmation gaps: "Request CO push on N confirmation gap(s)."]
[else if upcoming events exist: "Steady state. No confirmation gaps inside 14 days."]
[else: "All events executed or cancelled. TEEP needs refresh for next quarter."]

Add a Copy button next to the textarea that copies the brief to clipboard.

Show me only the changes needed (the button, the textarea, the JS function that builds the brief). Where in the file does each piece go.

BUILD #3 DECLARATION, fill all three lines in chat before opening your editor.

1. WHAT I'M BUILDING (one sentence, name the tool type and the user)
   Example: "A Combat Lifesaver currency tracker for the SACO."
   Example: "A range coordination checklist for the company gunny."
   Mine: ___________________________________________________________

2. MODE AND WHY (one sentence)
   Example: "Centaur, because currency rules are strict and the tool goes to the SACO."
   Example: "Cyborg, because I do not yet know if range coord is per-event or per-range."
   Mine: ___________________________________________________________

3. TWO SPECIFIC FRONTIER RISKS (one sentence each)
   Example A: "AI may not handle the FY boundary correctly in the date math."
   Example B: "Copy-to-clipboard may behave differently in Edge vs Chrome."
   If you cannot name TWO specific risks (not vague ones), revise this declaration before you start.
   Risk 1: ___________________________________________________________
   Risk 2: ___________________________________________________________

BUILD #3 DECOMPOSITION, answer all five before writing your first prompt.

1. INPUTS
   What does the user type or select?
   ___________________________________________________________

2. LOGIC
   What does the tool compute, route, or decide?
   ___________________________________________________________

3. OUTPUTS
   On-screen result? Printable view? Copyable text? All three?
   ___________________________________________________________

4. PERSISTENCE
   Does state need to survive reload? localStorage yes or no?
   ___________________________________________________________

5. EDGE CASES (list three)
   Empty input: ___________________________________________________
   Max input: ___________________________________________________
   Weird input: ___________________________________________________

FRONTIER MAP, starter rows for the static-HTML stack.

Add at least TWO specific rows of your own from today's builds.

| Task type                  | AI handles well                          | AI handles poorly                            | Verification needed                                  |
|----------------------------|------------------------------------------|----------------------------------------------|------------------------------------------------------|
| HTML form scaffolding      | Standard inputs, labels, basic validation| Accessible focus order, dependent fields     | Tab through the form. Submit with everything empty.  |
| Inline CSS for print       | Basic @media print, hiding nav chrome    | Color preservation, table page-breaks        | Actually print the page. Look at the PDF preview.    |
| Date math in JS            | Simple add and subtract                  | Timezone offsets, FY boundary, ISO parsing   | Test at start of October. Test at end of December.   |
| localStorage persistence   | JSON serialize and parse                 | Schema migration, quota, private browsing    | Open in InPrivate. Reload. See what survives.        |
| Copy to clipboard          | navigator.clipboard.writeText            | Fallback for older browsers and HTTP context | Test in Edge, Chrome, and on a phone.                |
| Color coding by status     | Class-based styling, status in class     | Inline-style approaches fighting specificity | Visually inspect every status value, all four.       |
| [Your row]                 |                                          |                                              |                                                      |
| [Your row]                 |                                          |                                              |                                                      |

What makes a useful row:
- Specific task type (not "AI stuff")
- Concrete examples in "Handles Well"
- Specific failure mode with enough detail to recognize next time
- A testable verification action (not "check it")

CAPABILITY GAP MAP, starter rows.

This artifact captures institutional capabilities Marines would deploy if access were granted. Compiled across training sessions, it forms the evidence base for tenant policy review at HQMC.

A single Marine asking for a connector is a request. Forty Marines documenting the same blocked connector with beneficiary counts and time savings is a policy case.

| Task Type                    | Prototype today (built today)               | Production wish (10x with access)               | Blocking permission / tool                   | Beneficiary count             | Time savings              |
|------------------------------|---------------------------------------------|-------------------------------------------------|----------------------------------------------|-------------------------------|---------------------------|
| Watch Bill Generation        | Static HTML, manual roster, github.io       | Pull roster from MOL, notify watchstanders      | MOL API not exposed; Office 365 connector    | 1 section leader x 8 sections | 1.5-2 hrs/wk per leader   |
| Training Calendar / TEEP     | Static HTML, localStorage, S-3 brief        | Two-way Outlook sync, shared resource pool      | Outlook connector license tier; Dataverse    | 1 S-3 per battalion           | 3-5 hrs/wk per shop       |
| Initial Counseling Tracker   | Static HTML NAVMC 11380 builder             | Direct write to MOL counseling record           | MOL no write API; no digital signature       | Every NCO USMC-wide           | 20-40 min per counseling  |
| Range Coordination           | Static HTML range request tracker           | Conflict detection vs RTAM schedule             | RTAM no documented integration surface       | Every battalion training shop | 2-4 hrs per range event   |
| Personnel Currency Dashboard | Static HTML CSV-import dashboard            | Live read of MCTIMS, push notifications         | MCTIMS read access restricted                | Every section leader USMC     | 30-60 min per section/wk  |
| [Your row]                   |                                             |                                                 |                                              |                               |                           |

What makes a STRONG row vs a WEAK one:

WEAK: "Power Apps not allowed"
STRONG: "Office 365 Outlook connector restricted at tenant level. Dataverse environment not provisioned. SharePoint write-back outside personal site disabled."

WEAK: "A lot of Marines"
STRONG: "1 S-3 shop per battalion, 4 battalions in the regiment, weekly use."

WEAK: "Saves time"
STRONG: "3 to 5 hours per S-3 shop per week, conservatively. Annual: 150 to 250 hrs per shop."

Instructor consolidates the room's rows and forwards through the unit AI POC to HQMC AI working group quarterly. Repeat hits across units for the same blocked permission are the strongest signal.