Files
Claro/docs/CLASSROOM_READINESS.md
Hermes Agent ed23524817 fix: harden Claro diagnostics and runtime guards
Preserve source locations, validate malformed JSON, and add opt-in resource limits. Include executable error-guide coverage, learner pilot materials, native Windows acceptance helpers, and updated CI/documentation.
2026-10-25 02:42:53 +00:00

47 lines
2.4 KiB
Markdown

# Classroom pilot checklist
**Status: ready for supervised learner testing, not classroom certification.**
Accessibility for learners with learning disabilities is a design goal and is
**not yet validated** by intended learners. Passing tests does not establish it.
Use [current status](CURRENT_STATUS.md) for scope, not older feature roadmaps.
The [ready-to-run pilot kit](LEARNER_PILOT.md) includes short tasks and a
[blank feedback form](LEARNER_FEEDBACK_TEMPLATE.md). No real session is implied.
## Before a session
- Use a build whose platform was actually tested; check `claro --version`.
On the legacy Windows build the executable is `claro98.exe`.
- Run `claro test` and `claro validate` in the extracted project folder.
- Prepare a writable practice folder and explain how to stop/close a stuck run.
- Use only reviewed, trusted scripts. Claro is not a sandbox and runs with the
learner's permissions; do not collect sensitive information in exercises.
## Observe the first hour
1. Run [hello](../lessons/01_hello.claro) and change its message.
2. Try [input](../lessons/02_ask_name.claro), variables and simple arithmetic.
3. Introduce one decision, then one small loop, at the learner's pace.
4. Follow the [ten lessons](../lessons/README.md) and [first-hour guide](FIRST_HOUR.md).
5. Try a small quiz; ask the learner to explain what changed and why.
6. Introduce a harmless mistake, run `claro check`, and observe whether the
message identifies the right line and suggests an understandable repair.
Show one recommended spelling per concept. Do not introduce classes, typing,
packages, networking, concurrency or graphics as prerequisites to first programs.
## Record feedback
- Can the learner start, run, change and save a program without repeated coaching?
- Which instructions, words, prompts or errors cause confusion?
- Are examples short enough? Is the expected output obvious?
- Can the learner recover from a mistake and understand what a loop does?
- What presentation, pacing or assistive-technology adjustments help this person?
Record observations without claiming one design suits every disability. Get
consent before retaining feedback and avoid unnecessary personal/health data.
Make one small improvement, then repeat learner testing.
Platform checks, hosted release verification and accessibility feedback are
separate milestones. See [release status](RELEASE_STATUS.md).