Job board

What the agents are asked

The first message sent when you use this template. You can edit the plan before anything is built.

Adapt this job board to my business. Keep both sides and every working rule: the seeker side (Jobs with search, filters, sorting and saved searches with simulated alerts, Job detail with an apply flow that keeps the CV in memory for preview and writes through the security definer function, Company pages, Saved jobs and Applications with a status timeline) and the employer side (Post a job as a multi step form with a live preview and a demo payment, Applicants pipeline as a kanban by stage with notes, ratings and a templated reject message, Company profile editor, Insights charts from views to applications per job). Change the brand, colours, industry, companies, locations, salary bands and screening questions to mine. Keep the sample data marked Sample and removable in one step, keep salaries realistic for Australia, and keep the general information line wherever the site touches employment advice. When I want real accounts and payments, wire in sign in, the tables and functions in schema.sql and Stripe Checkout as the README describes, with every secret key on the server.

A job board for Australia's climate and energy workforce: solar, wind, grid scale batteries, EV charging and home electrification. Seekers search real roles, apply with a CV kept in memory and a cover note, and track every application on a timeline. Employers ("Viewing as: Employer", acting as the sample company Meridian Solar) post roles through a multi step form with a live preview and a demo payment, run a kanban applicant pipeline, edit their company profile, and read insights charts from views to applications.

"Gridwork", Meridian Solar, Southern Cross Wind, Voltpath, Ember Retrofits and Basalt Grid Storage are invented for this template. The people (applicants, and the "you" who applies as a seeker) are invented too. Salaries are sample figures for the demo, not a market rate.

Files

There is no build step. Serve the folder with any static server that also serves /template-media/job-board/.

Screens

Seeker (bottom tab bar on a phone, top navigation on a desktop)

Employer (sidebar on a desktop, tab bar on a phone), acting as Meridian Solar

The data model (store in script.js, the same tables as schema.sql)

• companies: the five sample companies. is_employer_demo marks Meridian Solar, the one the employer screens act as; owner_user_id is how a real deployment knows which signed in user runs which company (see "Going live" below).
• jobs: status is draft, open or closed. Salary is stored as salary_min / salary_max / salary_period (year or hour); salaryAnnual() in script.js converts an hourly rate to a rough yearly figure so filtering and sorting compare fairly.
• job_view_events: one row per view, append only, counted rather than incremented, so nothing can be lost to two views landing at once (GENERATED-APPS.md, "money and counters are append only"). Debounced to once per job per browser session (sessionStorage).
• saved_jobs, saved_searches: a seeker's own rows. saved_searches.query is the same shape as the filter state in the Jobs screen; last_alerted_at is the watermark the "new matches" count and the alert strip are measured against.
• applications: status moves through applied, reviewing, interview, offer, hired or rejected. cv_filename and cv_summary are what the demo keeps: the file itself is read only into the browser's memory for the preview and is never uploaded anywhere in this template (see "Going live" for where a real upload belongs). A client side is_mine flag marks the rows the current browser actually submitted, standing in for user_id = auth.uid() until real sign in exists.
• application_events: append only, the timeline a seeker sees and the employer's history. A rejection's kind message lives here, on the rejected event.

Going live: from store/rpc to Supabase

Swapping localStorage for a real backend is a change inside store and rpc only; no screen touches either directly.

1. Sign in. Wire up Supabase Auth for both seekers and employers. A company becomes an employer's by setting companies.owner_user_id = auth.uid(); row level security in schema.sql already scopes every employer screen to that.
2. Applications, never through the table. rpc.submitApplication becomes a call to supabase.rpc('submit_application', { p_job, p_name, p_email, p_cover_note, p_cv_filename, p_cv_summary }), the SECURITY DEFINER function in schema.sql (L25: a public form writes through a function, never the table, so anon never holds an insert grant on applications).
3. The CV file itself. Upload it to Supabase Storage under a path keyed by the application id, and pass the storage path as cv_filename (or add a cv_path column). Keep parsing server side if a real text preview is wanted later; the demo's in browser preview only reads plain text files, and never claims to read a PDF's contents.
4. Stage changes, never a bare update. rpc.setApplicationStage becomes supabase.rpc('set_application_stage', { p_application, p_stage, p_message }), which writes the status and the timeline event together and checks the caller owns the job's company, so a stage can never change without a record of why.
5. Payments. The demo checkout button calls no network. Replace it with a real Stripe Checkout session created by a server function; only mark the job open after the webhook confirms payment, the same way the SQL function only ever sets status = 'open' from server side logic, never from a value the client sends directly.
6. Views. rpc.recordJobView becomes supabase.rpc('record_job_view', { p_job }).

Art direction

One shoot across five real Australian energy workplaces, shot in the hour around sunrise (one portrait lit by monitor glow at dusk to match its setting): low, raking side light, warm highlights against cool blue grey shadows, long real shadows, 24 to 85mm primes, fine film grain, muted natural colour, natural skin with no airbrushing. Every hi-vis vest and hard hat is plain and unbranded; no text, logos or watermarks in any frame.

Each company's photograph belongs to that company only, on every screen it appears: Home's company grid, that company's own page, and its jobs' "about the company" card all reuse the same one image rather than a second photograph of the same place.

What was deliberately left out of Phase 2

• Kanban drag and drop. Cards move stage through a Move to select, not a drag gesture. The select is keyboard accessible and cannot silently fail the way HTML5 drag and drop can in a sandboxed preview; a real drag interaction can be layered on top of the same rpc.setApplicationStage call later without changing the data model.
• Scroll triggered reveals. The premium bar's motion vocabulary is optional, not a checklist to exhaust. This template's one orchestrated moment is the apply confirmation (below); everywhere else content is visible at rest, with a page load stagger on Home only, so there is nothing that depends on an IntersectionObserver firing in a hidden tab (LESSONS.md L22, L24).

The signature moment

Submitting an application: the sheet snaps shut once like a switchboard breaker (is-energising in styles.css, skipped entirely under prefers-reduced-motion), then the confirmation replaces the form. The same submission also updates the job detail page behind the sheet from "Apply" to "Applied" before the sheet even closes.

General information

Salaries, company details and every person on this template are sample data for the demo, marked is_sample in schema.sql and removable in one step from the ribbon. Nothing here is a real job offer, a real salary benchmark or real employment advice.