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

2.4 KiB

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 for scope, not older feature roadmaps.

The ready-to-run pilot kit includes short tasks and a blank feedback form. 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 and change its message.
  2. Try input, variables and simple arithmetic.
  3. Introduce one decision, then one small loop, at the learner's pace.
  4. Follow the ten lessons and first-hour guide.
  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.