A question-led collection bench and twenty whole original aids

Manual local collection bench — source-author contract

A later source author builds a small transient manual bench, not an automated research or marking service. No NeuroForge/API assistant is enabled or invoked by this bank: quality has not been trialled for this workflow. Any future candidate integration needs a separate adult-reviewed quality/privacy/source gate. No account, identifiers, cloud saving, upload, external service/API request, generated source claims, auto-score or calibrated difficulty. Hosting a static page/assets may involve ordinary network delivery; do not promise that the site itself makes no requests. The bench itself sends entered material to no external service.

Start with all nine manual text areas truly empty. No held sources, keys, names or values in presets, examples or script data. Adult help starts closed; source/own/staff pages are distinct direct doors. Defaults may explain field labels but cannot fill a response. No diagnosis/learning-style selector. One field can be useful; no required personal fields or completion lock.

Nine fields

1. Collection question.
2. Item and source name/provider.
3. Source type/status: supplied fiction, reported fact, attributed account or actual observation only if it actually occurred.
4. Represented date/period and its job: made, used, collected, note written or unknown.
5. Supported detail and source passage/location.
6. Chosen sorting question/rule and placement, including unknown.
7. Attributed perspective and speaker, if present; no guessed universal view.
8. Supported connection/conclusion and proposed next step/current action status.
9. Unknown detail, actual wanted reader/self-check result if attempted, and helper attribution; missing stays missing.

Controls: Preview current entries as plain linear text; Edit; Copy as text only after a wanted action with a visible fallback; Clear with inline confirmation; Cancel; confirmed Clear. No automatic export/submit, no HTML interpretation, no innerHTML, no window.confirm, no aria-modal, no local/session storage. Use text nodes/textContent and labelled textarea values. Printable paper/spoken twin remains available without script. Empty/missing is not zero/incorrect; preview is not feedback.

Complete interaction and lifecycle

• Editing any field marks preview stale, clears copied/check status and invalidates a pending clear prompt. A new preview reflects current values without changing them.
• Preview makes a linear readable output with field labels and user-entered values only. Whitespace-only entries become blank display labels, not invented answers. Empty preview has a plain no-entries message. Never execute entered markup.
• Copy requests clipboard only from an explicit user action. Success/failure is reported accurately; failure offers selectable plain text/manual copy. No copied claim merely because requested. Copy does not leave a frozen correctness indicator after edits.
• Clear shows an inline, non-modal named confirmation with Clear and Cancel reachable by keyboard in normal order. Move focus to Cancel; no focus trap. Cancel or Escape cancels without erasing entries, returns focus to Clear and invalidates any pending stale/copy status. Confirmed Clear erases all nine fields, preview, copied status and pending prompt, then focuses the first field. Clear on empty remains a safe no-content interaction.
• pagehide: clear values, preview/copy/status/pending-clear state and any temporary clipboard fallback selection; no saved/retained claim. Do not attempt unwanted clipboard writes.
• pageshow: also clear those states, including BFCache/restore, and return the screen to a clean empty bench. A browser restoring a page must not restore a stale confirmation/result as current. Preserve no personal entered data between these events.
• Keyboard-only navigation, narrow/zoomed screen, reduced motion and print must keep readable sources, field labels, native help and confirmation. No drag-only, hover-only, colour-only or compulsory sound mechanism.

A pending Copy belongs to one current draft

• At the explicit Copy action, capture the nine exact current entry strings and the plain draft being copied, its output version, a unique request identifier and the current lifecycle generation. The copied text must correspond to that current draft; a visibly stale preview is not a current copied result. The request identity is distinct even if two requests contain the same words. An opaque token or increasing generation must never reuse an earlier identifier in this document, including after reset, pagehide or pageshow.
• Before changing the interface, both success and failure completion, and any completion cleanup, must verify that this is still the latest request for those same current entries, output version and lifecycle. Only a still-current success may say that this captured current draft was copied. Only a still-current failure may offer its matching selectable plain-text fallback. A superseded completion does nothing to the interface: it cannot restore an old preview or hidden text, copied/check status, fallback text or selection, pending controls, focus or a newer draft's status. Do not let an old completion's final cleanup remove a newer request's pending state.
• Invalidate all earlier pending Copy work on every field edit, a new Preview, a new Copy request, opening Clear, Clear Cancel or Escape, confirmed Clear, pagehide and pageshow. Invalidation clears bench-owned copy status, fallback text/selection and pending-copy references; it never erases current entries during an ordinary edit or Cancel/Escape. Editing still marks the existing preview stale; a new Preview supersedes it. Cancel/Escape still returns focus to Clear and keeps the chosen work. Confirmed Clear and both lifecycle events retain the complete empty-state contract above. Editing away and back to the same words cannot make an earlier request current again.
• Invalidation is local interface control, not cancellation or erasure of the system clipboard. An already-requested clipboard write may still finish externally after becoming stale; do not advertise that stale result as current success, read the clipboard to check it, or issue an unwanted replacement write. Clearing the bench does not erase an external clipboard or a deliberately retained paper copy. No pending promise outcome may repopulate the returning page.

Actual fixtures required of the later source

No fixtures have run at proposal stage. Later author runs its actual shipped tool handlers against empty/current/stale-preview states; edits during pending clear; Cancel by button; Escape; keyboard focus return; confirmed clear; whitespace input; literal <script> text; copy success/failure fallback; ordinary preview/source-status changes; pagehide/pageshow/BFCache-like lifecycle clean state. Include the six paper scenarios below and source→own→staff navigation. Separate actual Browser use through the shipped page must verify visible controls, native help, keyboard Cancel/Escape, edit invalidation, source rights/reference doors and empty own spaces. Handler fixtures are not Browser use, and Browser use is not learner/teacher field acceptance. Keep exact receipts and no substituted wrapper implementation.

For the later actual shipped handlers, register both success and failure settlements for each of these six case groups before execution: (1) pending Copy then edit each of the nine fields, including edit-away-and-back; (2) pending Copy then a new Preview; (3) two distinct Copy requests finishing out of order, including identical words; (4) pending Copy then open Clear followed by Cancel or Escape, preserving entries and required focus; (5) pending Copy then confirmed Clear, preserving nine empty fields, empty output/status/fallback and first-field focus; (6) pending Copy then pagehide and pageshow, separately and as a leave/return pair, with no visible or hidden words/status/fallback restored. Also verify current success and current failure/manual fallback so stale guards do not disable valid wanted copying. For every stale settlement assert current entries, current output/version/status, pending controls and actual selected/focused target stay as specified. These are future test requirements, not executed fixtures or Browser results.

Complete paper/spoken twin

Use nine labelled blank spaces matching the fields above. Adults can read one label at a time; child can dictate/sign/AAC/direct marks. No diagnosis or personal identifier required. Full selected source stays available. Record helper writing/operation apart from child choice. A simple spoken account of selected fields is complete; no need to fill every box.

• Collect: choose a question and source; enter only actually chosen relevant details, source/status/date-job/rule/perspective/connection/unknown. Unanswered fields remain blank/unknown, not wrong.
• Preview: read the current entries linearly. Mark draft if changing; a new draft supersedes a copied old version without claiming it was erased elsewhere.
• Copy: if wanted, make a paper/transcribed copy and name who wrote which part. A proposed copy is not made until actually copied. If the working draft changes while a helper is copying, check which version was actually copied and keep it labelled as that version. Do not call an older copy the current draft or imply Cancel/Clear removed a retained copy.
• Clear/Cancel: say what would be discarded and ask for a wanted decision. Cancel keeps all work; confirmed clear removes only the chosen working sheet/marks under the adult's normal arrangements, never another retained copy. No compulsory destruction of learner work.
• Leaving/returning: choose a wanted paper copy before leaving. Start a fresh empty working sheet on return; retained copies are deliberately kept records, not automatic bench persistence. Keep no false digital retention promise.
• Six local scenarios: (1) no entries yet: blank, not zero; (2) source detail read and retained, no own conclusion: separate source/own; (3) date/source changed: mark old preview stale and read new version; (4) pending clear then edit: cancel the old decision and retain current work; (5) cancel: keep chosen work and return to making; (6) two entries made, reader reply absent: keep actual creation and unknown result, no invented success.

This is the retained author contract, not a statement that a Browser or classroom gate has passed.

Sources and reuse · Original educational work © NeuroForgeIO Pty Ltd 2026, CC BY 4.0. Linked authority/provider exceptions and learner ownership stay separate.