Project Phases and Status
Phased delivery thread, success measures, and current validated status.
Delivery phases
| Phase | Name | Intent | Reading |
|---|---|---|---|
| Phase 1 | Discovery and problem framing | Clarify the event intent, identify participant friction, inventory the repo, and test whether the original technical assumptions were fit for purpose. | Completed retrospectively from execution evidence and resulting architecture decisions. |
| Phase 2 | Investigation and proof of concept | Explore browser-first, VM, and fallback paths; test what GitHub Pages can realistically support; identify what must stay static versus what needs a supplemental service. | Completed with architecture correction toward browser-first and static-site constraints. |
| Phase 3 | Delivery design and content build | Build the public site, learner exercises, role packs, facilitator materials, readiness logic, and packaging flow. | Completed and validated in the repo. |
| Phase 4 | Rationalization and control tightening | Archive legacy material, normalize file locations, align naming, strengthen validation, and remove misleading participant-facing technical drift. | Completed and validated in the repo. |
| Phase 5 | Production readiness and positioning | Harden README, public front door, platform model, PM artifact layer, and portfolio narrative for presentation outside the event itself. | Current pass. |
Success measures
| Measure | Definition | Evidence route |
|---|---|---|
| Participant path | A youth participant can complete the core session in a browser without local VM setup. | Validated through architecture, public pages, exercises, reflections, and readiness outputs. |
| Parent trust | Families can understand what the event is, what it is not, and what is not required by default. | Validated through parent pages and parent information pack content checks. |
| Facilitator readiness | A facilitator or backup facilitator can run the 90-minute session from finished materials. | Validated through run-of-show, answer key, talking points, and backup pack checks. |
| Operational repeatability | The repo can rebuild, validate, and package deterministically. | Validated through build, validation, archive, and packaging scripts plus artifacts. |
| Scope control | Advanced technical paths remain secondary and do not displace the browser-first model. | Validated through public messaging, docs, and readiness routing. |
Current status
| Area | Status | Notes |
|---|---|---|
| Public browser-first pages | validated | Built from scripts/build_delivery_system.py and checked by validate_delivery_system.ps1. |
| Facilitator and backup packs | validated | Generated HTML docs and checked for required presence and key content. |
| Exercise and reflection system | validated | Prompt cards, scaffolds, local browser saving, JSON download, and print/PDF report flow are present. |
| Platform model docs | validated | GitHub Pages limits, client-side workbook behavior, Forms strategy, and optional backend supplement are documented. |
| Pre-event messages | completed but not live-tested | Content is ready to send but real audience response is still outside repo scope. |
| Organizer-owned Google Form URLs | blocked | Google Forms is the canonical survey path, but actual organizer-owned form URLs cannot be created inside this repository. |
| GitHub Pages publish mirror | validated | The github/ publish mirror contains the deep routes required for exercises, reflections, and KB pages. |
| Optional VM path | completed but secondary | Retained as optional/operator-only material. |
| Archived legacy VM-first material | archived | Moved out of the active participant path. |
| Current package overlay | validated | Fresh overlay built under .ai_uploads after validation. |
| Real event-day staffing names | next work | Needs organizer-specific names if they change. |