# One-event volunteer app: completed and blank pilot card

Use this card to decide what your first app must do. The completed example is fictional. It is not a working roster, submitted signup, saved record or verified template behavior. Use sample information during app tests.

## Completed pilot: Cedar Welcome Day

**Job:** the incoming coordinator can identify the current roster, recorded arrivals and one unresolved action without exposing volunteer records publicly.

**Event:** November 14, 2026, America/New_York. All sample times are event-local; this card performs no timezone conversion or calendar export.

**Authority:** Morgan owns the roster before the 09:10 handover; Lee owns it afterward. The handover is explicit. Requests from volunteers are proposals until the current coordinator confirms an assignment. The existing operating roster remains in use until the pilot passes its tests.

**Scope:** one event; staff confirmation of shifts; cancellation history; recorded arrival; one handover. No payments, external messages, automatic matching, timed holds, waitlist or recurring events. No confirmation or reminder email is implied.

### Shifts

| Shift ID | Task | Local start–end | Required confirmed people |
| --- | --- | --- | --- |
| S1 | Welcome | 09:00–10:00 | 2 |
| S2 | Sort | 10:00–11:00 | 2 |
| S3 | Cleanup | 11:00–12:00 | 1 |

### Assignment history at 09:10

The names and IDs below are fictional. The roster is coordinator-only in the proposed app.

| Assignment ID | Person ID / display name | Shift | State | Replaces | Recorded arrival |
| --- | --- | --- | --- | --- | --- |
| A01 | V01 / Ada | S1 | Confirmed | — | 08:57, observed by Morgan |
| A02 | V02 / Bea | S1 | Canceled | — | None |
| A03 | V03 / Cam | S2 | Confirmed | — | None |
| A04 | V04 / Dev | S2 | Confirmed | — | None |
| A05 | V05 / Eli | S3 | Confirmed | — | None |
| A06 | V06 / Fay | S1 | Confirmed | A02 | None |

Before the event, Morgan recorded Bea's cancellation and confirmed Fay as the replacement. The cancellation does not delete A02, and A06 does not overwrite Bea's identity.

### Expected reconciliation

- Six historical assignment rows = five confirmed + one canceled.
- Active assignment IDs: A01, A03, A04, A05, A06.
- Active person IDs: V01, V03, V04, V05, V06. Five different people in this example; do not assume assignment count always equals person count.
- Required places: `2 + 2 + 1 = 5`. Confirmed by shift: S1 = 2, S2 = 2, S3 = 1. Unassigned places at this checkpoint: 0 for every shift.
- At 09:10, S1 is in progress: A01 has an observed arrival; A06 has no arrival record.
- S2/S3 have not started. A03, A04 and A05 remain future-shift assignments, not no-shows.
- The canceled A02 contributes to neither active capacity nor expected arrivals.

The example assesses arrivals only for the shift in progress. It defines no automatic late/no-show threshold, no rule for a completed shift and no proof that a checked-in person is still present or has completed their task. Define additional rules only when your workflow needs them.

### Visibility and change boundary

| Record or action | Visitor | Volunteer with verified access | Authorized coordinator |
| --- | --- | --- | --- |
| Public event, tasks, start/end and unassigned-place totals | Read | Read | Maintain |
| One volunteer's request and assignment | No individual record access | Read own record | Read/manage for this event |
| Contact details and arrival records | No access | Own information only, where needed | Access only for event operations |
| Another person's record | No access | No access | Access for this event only |
| Confirm/cancel an assignment or record an arrival | No | Request a change; no direct roster mutation | Yes, under the event's rules |
| Private handover note | No access | No access | Read/update |

Name or unverified email alone is not authorization. Define a verified identity method and enforce access on the server. No login method or privacy behavior is established by this worksheet.

### Handover at 09:10

- Outgoing coordinator: Morgan.
- Incoming owner: Lee.
- Record requiring attention: A06 / Fay / S1.
- Known: assignment confirmed; no arrival recorded.
- Unknown: whether Fay has arrived without being recorded.
- Next action: Lee checks the welcome desk, then records the outcome or a further owned action.
- Due: 09:15 event-local.
- Do not infer: a no-show, cancellation, replacement or message delivery from the clock alone.

### Acceptance record

Expected outcomes below are authored requirements. No app tests have been performed by this card.

| Check | Expected | Observed | Status |
| --- | --- | --- | --- |
| Submit a fictional shift request | Request is visible to the correct coordinator and clearly pending; it is not already a confirmed place | — | Not tested |
| Coordinator confirms it, then leaves and returns | Same assignment/person/shift/state remains; volunteer can see only their own confirmation | — | Not tested |
| Cancel A02 and confirm A06 | A02 retained; A06 links to A02; five active assignments remain | — | Not tested |
| Open the 09:10 view | One recorded S1 arrival, one unresolved S1 arrival, three future-shift assignments | — | Not tested |
| Lee opens the handover in a separate authorized session | Same roster and A06 action/owner/due time; private notes remain private | — | Not tested |
| Visitor or other volunteer opens a copied private URL | Access denied; no private record is returned | — | Not tested |
| Pass 09:15 without recording an outcome | Action remains unresolved; no invented attendance or automatic cancellation/message | — | Not tested |
| Use the request and own-confirmation screens on a phone | Labels, errors and next step remain usable; no hidden requirement or unintended record exposure | — | Not tested |

## Blank pilot card

### Decide whether to build

- Event and intended coordinator:
- Current form/roster and the specific handover problem:
- What already works and will stay in place?
- Keep the process, inspect a starter, evaluate a maintained product or prototype? Why?
- Who maintains the app and roster?
- Cost/usage assumptions that are known:
- Costs or capabilities still unknown:
- Smallest observation that would change this decision:

### Define the first event

- Date, event timezone and meaning of each displayed time:
- Shift/task/start/end and required people:
- When is a request received versus an assignment confirmed?
- Who is allowed to confirm, cancel or replace an assignment?
- Stable assignment and person identifiers:
- How cancellation history and replacements are linked:
- What an arrival record proves, and who records it:
- How current, future and completed shifts are distinguished:
- Public fields:
- Own-volunteer fields and verified access method:
- Coordinator-only fields:
- Authoritative roster and handover rule:
- Features deliberately outside this pilot:

### Work one cancellation and handover by hand

| Assignment | Person | Shift | State | Replaces | Arrival evidence |
| --- | --- | --- | --- | --- | --- |
| | | | | | |
| | | | | | |
| | | | | | |

- Historical rows = active + canceled/other explicit states:
- Active assignment IDs and distinct person IDs:
- Confirmed/required/unassigned counts per shift:
- Checkpoint time and current/future shift classification:
- Known arrival evidence:
- Unresolved record, next owner, action and due time:
- What must not be inferred automatically?

### Record the actual tests

| Check | Expected | Observed | Status / evidence |
| --- | --- | --- | --- |
| Request and confirmation | | | Not tested |
| Saved state after return | | | Not tested |
| Cancellation/replacement counts | | | Not tested |
| Second-coordinator handover | | | Not tested |
| Direct private record access | | | Not tested |
| Unresolved action after due time | | | Not tested |
| Phone journey | | | Not tested |

- Owner and review date:
- What stops the pilot?
- What stays authoritative until a replacement is accepted?
- Next requirement to investigate, only after this pilot works:

## Continue in Overskill

Inspect Rally: https://www.overskill.com/templates/rally

Real remix entry: https://www.overskill.com/remix/eRxrXj

Review and edit the brief, then choose Start build: https://www.overskill.com/learn#brief-builder

Private-record checks: https://www.overskill.com/learn/verify-private-record-access

If you need capacity or a waitlist policy: https://www.overskill.com/learn/plan-workshop-seats-and-waitlist

These are starting points and test methods. They do not establish that a template already implements this pilot. Sign-in, account access, credits and later configured-app verification remain separate.