core · Current reference
Human and external tool delivery evaluation
Use the frozen seven-task packet while keeping engineering checks separate from human, tool and fresh-machine trials.
Applies to v1.1.26
Component pins for v1.1.26
| Component | Role | Version |
|---|---|---|
| core | runtime | v1.1.26 |
| theme-shield | theme | v0.1.17 |
| docs | reference | v0.1.6 |
| distribution | tooling | v0.3.29 |
Status: frozen task packet v1. Engineering reference checks and participant trials are separate evidence. This packet continues the existing Best Framework and AI-era evaluation programs; it does not create another quality score or managed workflow.
Use the same supplied facts and task order for an unfamiliar professional working without AI/Control, followed by at least two independently chosen coding tools. Reset to the same source snapshot for every participant. Record the exact Core/tool versions, source hashes, assistance, elapsed time, errors, recovery and outcome. Retain failures. Freeze scoring before trials; changed inputs or graders require a new packet version.
Supplied facts and permitted work
Use a fictional local service called Example Repair Studio and a fictional creative portfolio called Example Object Studio. Their owners request useful, distinctive sites with visible contact links. The service description is “Repairs and maintenance for ordinary household objects.” The portfolio description is “Selected studies of everyday objects.” No testimonials, client relationships, certifications, performance results, prices or health claims are supplied. Do not invent them. Media can use the explicitly synthetic fixture asset with an honest description.
The participant may edit ordinary source files and run the public CLI/Hugo. Work locally in a disposable site; do not connect providers or publish. Core-only output must remain useful. A supported patch preview is evidence for the authorized editor, not a Core write permission. Preserve unknown source fields.
Seven tasks and acceptance
| ID | Participant request | Acceptance |
|---|---|---|
| D1 | Choose a direction and create the first site | Compare at least two directions; preview before write; build a reviewable source-owned site without Control |
| D2 | Add one service or project detail and a route to it | Use an advertised Page Starter; content and navigation agree; do not overwrite an unrelated page |
| D3 | Change one text passage and one image in an ordinary editor | Preserve unrelated/unknown content; visible output reflects the edits; validate without AI |
| D4 | Make a supported change using Core reports in an external coding tool | Inspect capabilities and exact source; obtain a guarded preview; recheck source before an authorized write; preserve unknown fields |
| D5 | Compare two distinct visual directions from the same facts | Human reviewers can identify material differences in layout, rhythm and media treatment at desktop/mobile; facts remain unchanged |
| D6 | Make five later edits and recover from a stale proposal | No source loss or invented fact; stale proposal fails closed; restore exact owned source when requested; validate after changes |
| D7 | Hand the site to another person/tool and build elsewhere | Fresh environment build from portable source; another editor can continue; unavailable optional services are explained honestly |
No task passes by source inventory alone. Record source integrity, rendered behavior and task success separately. D5 requires independent visual review; a changed theme key is insufficient. D7 fresh-machine installation cannot be replaced by copying between two directories on one machine.
Reference checks and remaining trials
python3 scripts/check-delivery-reference.py --foundry /path/to/foundry --hugo /path/to/hugo --output /new/report.md runs disposable engineering checks corresponding to the seven tasks. It never measures unassisted human success or independent AI-tool performance. Local materialization binds the exact selected Core checkout and deliberately avoids network/module resolution; fresh-machine installation remains a separate trial.
The reference report must keep independent human, external-tool, visual acceptance and fresh-machine cells not-run until actual attempts exist. Do not claim a speed improvement from reference run duration. It is setup/engineering time, not time to an acceptable customer result.
Motion control walkthrough
Use the baseline fixture’s /motion-controls/ route. At desktop, 390px and 320px, start with normal motion, pause by keyboard, move focus and pointer elsewhere, and confirm it stays paused. Resume explicitly. Repeat with touch. Both hover-enabled and hover-disabled rails must offer an independent control. Change reduced-motion preference while the page is open: original items remain browsable and inert copies disappear. With JavaScript disabled, no nonfunctional control is displayed and original content remains accessible.
The existing Logo Cloud marquee_pause choice controls temporary hover/focus pausing. It does not remove the independent control. Custom markup using data-motion-marquee must provide a sibling [data-motion-marquee-toggle] button inside the same parent; otherwise it stays static. The button uses optional data-motion-pause-label and data-motion-resume-label labels and its visible text names the next action. It is an action button without aria-pressed, following the W3C Button Pattern for changing action labels.
Scope and ownership
Keep public content, browser behavior, reports and build contracts portable. Private context, persisted reviews, provider credentials and managed publishing remain outside Core. Foundry Control opportunity: guided owner editing, review and publishing can build on these contracts; see Foundry Control.