Add Per Scholas capstone project memory, link to osTicket/kscloud1 plan

project_per_scholas_capstone.md

@@ -0,0 +1,47 @@
+---
+name: project-per-scholas-capstone
+description: "Per Scholas \"IT Support Capstone: Migration & Stabilization\" team challenge - connected to the osTicket/kscloud1 deployment work"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: 1676d7da-0a11-47f0-b4b5-1dc606389531
+---
+
+kenpat is doing the Per Scholas "IT Support Capstone: Migration & Stabilization -
+Team Challenge" (Version 2.0, Jan 2026), source PDF: `Downloads/CAP 129.2.1 - IT
+Support.pdf`. Team-based workplace simulation: respond to a migration event,
+investigate user-reported tickets, stabilize systems, report findings.
+
+**5 phases (sequential):** 1) Environment & Baseline (build VirtualBox Windows
+Server + Windows Client VMs), 2) Migration Event, 3) Incident Response
+(investigate user tickets), 4) Stabilization & Recovery, 5) Reporting &
+Presentation.
+
+**AI usage rules (per the assignment):**
+- AI = "junior assistant", not authority - draft scripts/docs/troubleshooting
+  suggestions only.
+- Every AI-assisted recommendation must be MANUALLY VERIFIED by kenpat with
+  evidence (screenshots, command output, config views) - I should not present
+  conclusions as final without prompting verification.
+- "Individual Environment Requirement": each learner builds/operates their OWN
+  VirtualBox VMs - I cannot do this hands-on work for them, only advise/guide.
+- Final deliverables: team Capstone Technical Report + Executive Summary, plus
+  an Individual Evidence Appendix labeled per learner.
+
+**Why:** kenpat confirmed (2026-06-13) the capstone and the real osTicket +
+Authentik SSO deployment on kscloud1 are CONNECTED - the capstone's
+incident-response/ticketing workflow is meant to be practiced using the real
+osTicket instance being stood up on kscloud1 (Hetzner). Decisions made so far:
+- osTicket + its required MariaDB will be deployed on kscloud1 NOW (not waiting
+  on the stalled Oracle VPS migration, see [[project-kitestacks-migration]]).
+- Both end-user ticket submission (osTicket's native client portal) AND
+  staff/agent SSO via Authentik (needs a 3rd-party OAuth2/SAML plugin, unlike
+  Kavita's built-in OIDC) are needed.
+
+**How to apply:** When helping with capstone phases, give guidance/explanations
+the user can act on themselves and remind them to capture evidence - don't
+narrate AI work as if it satisfies the assignment's verification requirement.
+When deploying osTicket/MariaDB on kscloud1, follow the same patterns as the
+existing kscloud1 stack documented in [[project-kitestacks-migration]] (one
+dir per app under /opt/kitestacks/docker/, joined to the `kitestacks` docker
+network, shared Authentik Postgres/Redis over Tailscale for SSO).