VELESRELAY 1.0.0 · FIELD GUIDE

A break is more than
the time away.

Plan the walk, the handover, the relief cover and the return. Then give each person the same version of the plan.

Original fictional example · Local browser app · No account

1. Open the app and make your first route

Extract the entire buyer ZIP to a normal folder. Open app/index.html in desktop Google Chrome. Keep the app, manual and screenshots folders together. No installation, command line, server, internet connection or account is needed. The separate free pack contains this guide, example data and a printable worksheet; it does not contain the app.

Tested on Linux with Google Chrome 152.0.7977.82 using a fresh browser context and networking disabled. Other operating systems, browsers and physical printers have not been verified. The interface was checked at 1440 and 390 pixels wide; at narrow widths the full route is shown as chronological cards, and tables and the step rail scroll horizontally.

  1. Choose Load Orchard Fair, then Propose route in Review.
  2. Check the post cards and rover itinerary. Expected result: all three breaks assigned to Remy, with 60 minutes cover + 30 minutes handover + 30 minutes walking = 120 minutes.
  3. Open Issue papers, issue revision 1, save the project, then preview and print the papers.
Running VelesRelay with the Orchard Fair route, three assigned breaks, labelled timeline and chronological rover itinerary
Actual running app: the complete original route. Open the image for full-size details. All names and events in this guide are fictional.
Remy’s routeTime
Depart HQ; arrive at A09:50 → 09:55
A handover / absence / handback09:55–10:00 / 10:00–10:20 / 10:20–10:25
Walk A → B10:25–10:35
B handover / absence / handback10:35–10:40 / 10:40–11:00 / 11:00–11:05
Walk B → C11:05–11:10
C handover / absence / handback11:10–11:15 / 11:15–11:35 / 11:35–11:40
Return C → HQ11:40–11:50

2. Set up your own event

The intended buyer is a small-fair volunteer coordinator who already has a fixed base rota for welcome, information or exhibition posts. VelesRelay plans relief around that rota. It does not build staff shifts or establish break entitlements.

  1. Posts. Start a new blank plan. Enter event name, date, hours and the duration of each handover. Add fixed posts with a unique post ID, name, incumbent ID/name and role. Apply your edits.
  2. Relief team. Add rovers with one availability interval and start/return locations. Add their eligible roles. Locations are post IDs or the reserved base HQ. Incumbent IDs and rover IDs must be distinct.
  3. Walking and unavailable time. Enter each needed directed leg. A → B does not imply B → A. Missing travel is unavailable; the same location takes zero minutes. There is no map or automatic route inference. Add rover breaks or other duties as unavailable intervals.
  4. Breaks. Enter each request ID, post, earliest absence, latest return and absence duration. All times and durations use five-minute steps.
  5. Review. Propose, inspect conflicts and unresolved IDs, then adjust or pin placements. Issue papers only after checking the supplied inputs with your team.

Apply buttons save all visible table edits together. On Posts they also apply event settings. Adding or removing a row is not committed until Apply. Unapplied edits block step changes and project saving. Undo restores the last applied edit (pressing again toggles the two states); it also discards current unapplied fields. To remove a referenced post or rover, first unassign its breaks and remove the referencing input rows.

What “break” means here

The absence is total time away from the post, including any walk to refreshments. The rover arrives for the first handover before the absence, then stays for handback after the incumbent returns. Handovers are shared transitions, not another independent cover person.

A rover departs their start location just in time for the first handover, waits at the previous post before a later departure, and returns directly after the last handback. The whole tour, including waits, must avoid unavailable intervals. This conservative single-tour model does not split a route into separate tours around other duties. No movement is inferred during unavailable time.

3. Import your own files

For bulk entry, adapt the six CSV files in examples/. Use Posts → Import six CSV tables and select all six together, even if eligibility or blocked files contain only the header. Filenames and headers must match exactly. Set event hours first. All six tables are checked as one transaction; a failed import leaves the current plan intact. Successful import clears draft assignments and pins but preserves issued history.

FilenameExact header
posts.csvpost_id,label,incumbent_id,incumbent_name,role
rovers.csvrover_id,name,available_start,available_end,start_location,end_location
eligibility.csvrover_id,role
travel.csvfrom_location,to_location,minutes
breaks.csvbreak_id,post_id,earliest_start,latest_end,duration
blocked.csvrover_id,start,end

Use UTF-8 comma-separated CSV, optional BOM, LF or CRLF line endings, and quote cells containing commas or quotes. Double a quote inside a quoted cell: "Welcome, ""Orchard""". The parser understands CSV quoting; name fields reject embedded newlines and other control characters. Times are HH:MM on a five-minute grid. Duplicate IDs/relationships, missing columns and unknown references are rejected. IDs use 1–32 ASCII letters, digits, underscores or hyphens; names and roles use 1–80 plain-text characters, without angle brackets. Duplicate display names are allowed: use IDs to distinguish them.

To restore an entire project, use Open project and select a downloaded schema-1 JSON file. This preserves inputs, assignments, pins and approved revisions. JSON is the authoritative editable record; assignment CSV is a report, not a project import format.

4. Repair a late return without rewriting history

First issue Orchard Fair revision 1. Back in Review, expand Try the late-return example and choose Apply B delay + return route. This extends B to 11:10, pins A/B and explicitly adds a 15-minute B → HQ return. That return is new input, not a route inferred by the app. Propose again: C is unresolved. Remy’s handback at B ends at 11:15, too late to arrive at C for its 11:10 handover.

Running app showing a partial plan and unresolved BR-C after B is delayed
Partial draft: C remains visible, with local route conflicts. The previously issued revision is unchanged.

Choose Add backup Jo at C, then propose again. Jo is info-eligible and starts/finishes at C, available from 11:10. Jo covers C’s unchanged 11:15–11:35 absence. Remy returns B → HQ at 11:15–11:30. The new totals are 70 minutes cover, 30 minutes handover and 30 minutes walking across two rovers. Issue revision 2: the replacement checklist names posts B/C and rovers Remy/Jo.

Running app showing the repaired Remy and Jo routes with all three breaks assigned
Jo repairs the unchanged C request; revision 1 remains available in the paper-source menu.

For your own repair, edit input times in Breaks, then use Review’s assignment controls. Choose a rover, absence start and optional pin; Apply revalidates all manual placements. A pin must have an assignment. Invalid pins block proposal. Invalid manual routes stay visible as draft conflicts and cannot be issued or printed. Proposals may replace unpinned manual assignments. Unresolved requests remain visible; a partial plan is never labelled complete.

Search explores at most 100,000 states and also has a five-second wall-clock cutoff. Results report incomplete exploration when capped. The search prefers more assigned breaks, then less walking, then earlier starts among the routes it finds; it does not prove optimality or global impossibility. Pin validation and chronological construction can exclude routes that would need intermediate inserted visits. If no feasible returned tour containing the pins is found, the existing draft is retained. The interface may pause briefly during calculation.

5. Issue, export and reopen

Issue revision creates an immutable snapshot in this project. It records a plan based on supplied inputs, not attendance or approval by other people. Save the project after issuing. Edits change the working draft; the paper-source menu lets you preview or print any prior revision without restoring it over your draft.

The combined papers contain the summary, one sheet per post, one itinerary per rover, unresolved requests and a replacement-sheet checklist. Long sheets continue onto further pages. Every printed page identifies the event/date/revision and planned or partial status. Choose Print / save PDF, A4 or Letter, portrait, default margins and 100% scale in Chrome. Disable Chrome’s own headers/footers. Review the preview and communicate changed instructions yourself; the app sends nothing.

Actual issued-revision screen and preview of post and rover papers
Revision selection, exports and actual in-app paper preview.

Save project downloads a JSON file. The app has no autosave or browser storage: keep the downloaded file and reopen it next time. A “download requested” message means the browser received it; check your Downloads folder. The unsaved badge tracks in-memory changes. Original imported files are never overwritten. Use clear filenames for retained copies.

Canonical assignment CSV preserves labels exactly and includes unresolved requests/status. Spreadsheet-safe assignment CSV separately prefixes formula-leading cells (including leading whitespace followed by = + - @) with an apostrophe. Canonical input-table exports retain original text too. Use the safe report when opening formula-like names in spreadsheet software. All CSV exports describe the current working draft, not the selected old paper revision.

Limits, privacy and scope

Supported boundLimit
EventOne date, same-day, at most 16 hours; no timezone or midnight crossing
People and work12 posts/fixed incumbents, 6 distinct rovers, 40 requests, 12 post roles
Relationships72 eligibility rows, 100 directed travel rows, 24 unavailable intervals
TimingFive-minute grid; absences 5–120 minutes; walking 0–120 minutes; each handover 0/5/10/15 minutes
Files and history1 MiB per CSV, 5 MiB per saved JSON; 20 issued revisions per project

Files are processed locally in browser memory. There are no runtime libraries, network calls, telemetry, cloud accounts or synchronization. Anyone with a downloaded project can read its names and schedules. Store and share files accordingly. To uninstall, close the tab and delete the extracted folder and any downloads/PDFs you no longer need. The app creates no background service or account.

This tool supports ordinary information/welcome/exhibition relief planning. It does not establish suitability for security, medical, traffic or safeguarding coverage, calculate legal break entitlements, verify real attendance or guarantee operational coverage. No calendar import, messaging or staff shift allocation is included.

Troubleshooting

SymptomWhat to do
Nothing assigned / unknown travelCheck start→first post, all directed transitions and last post→return location. Missing edges are never zero. Use explicit measured values.
Blocked proposalCorrect or unpin conflicting visits. Check eligibility, both handovers, availability and return travel. No feasible result is a local search outcome, not proof no arrangement exists.
Cannot change steps or saveApply edited fields first. Undo discards unapplied fields and restores the previous applied state. Imported bad files do not modify the plan.
CSV rejectedSelect all six exact filenames, check headers/references and use UTF-8 with commas. A spreadsheet’s semicolon export is not supported.
Blank app / missing stylesExtract the whole ZIP, keep folders together, and open app/index.html in Chrome rather than viewing inside an archive or email preview.
Print seems different from draftCheck the paper-source revision selection. Use current draft for new papers; a saved old revision intentionally retains earlier instructions.
Too many revisions or large JSONKeep the old project file as an archive. Start a new blank project and import the six exported input tables; this starts a new history.
Small screenRead the chronological itinerary instead of the timeline. Scroll tables horizontally for pin/apply controls. A desktop display is recommended for extensive editing.
Actual 390-pixel-wide app displaying chronological route cards
Narrow layout: labelled chronological instructions are retained.