Harborlight

Your muse
Build Harborlight, a complete operations suite for the made-up Saltmere Ferry Cooperative, an invented island ferry company. All people, boats, routes and numbers are made up. This is a big, multi-part product, so please split the work across subagents, one per part, and take as long as the quality needs. Do the whole thing, not a sketch. Parts: 1. Public booking site: timetable for 6 invented routes, seat and vehicle booking, fares by season, booking lookup by code, and a cancel flow. 2. Dispatcher console: a live board of 8 boats, drag to reassign crews, delay and weather notices that update the public site, and a day replay. 3. Crew app: shift calendar, swap requests with approval, hours limits with warnings, safety checklists before each sailing. 4. Maintenance tracker: parts inventory, work orders, boat downtime calendar that blocks bookings when a boat is out, and overdue alerts. 5. Finance reports: revenue by route and season, fuel cost per crossing, refunds, CSV export, and charts. 6. Passenger assistant: a chat helper on the public site that answers from the timetable and notices using saved data, and hands off to a person. 7. Admin: roles for dispatcher, crew, mechanic and finance, an audit log of every change, and seed data with at least 90 days of made-up history. Every part must share one real database and work end to end: a booking made on the public site must show on the dispatcher board, a boat taken out for maintenance must block new bookings and notify affected passengers, and finance must see refunds. Write automated tests for every part and run them. Test all the cross-part flows in a browser and fix what fails before finishing. Make the look distinctive and calm, like a harbor at dawn, on phones and desktops.
Checks found problems
Smoke test, caps
From the owner: Stop the run.
Delivered
Milestone 2 is built and the build record is updated. A final full npm run verify was not run after the last fixes because this round already used its two allowed verify runs.
Fixed from the last check
- The live stream failure: the smoke test now launches its browser so it can reach the stream, and the dispatcher board renders operations_board changes from useLive in app/dispatch/page.tsx.
- Shared writes now retry once after a short wait in lib/harbor-server.ts, which fixed intermittent swap, checklist and cancellation failures.
- Boat capacities are now invented ferry sizes, so repeated bookings in the shared build space do not fill a sailing.
Milestone 2 additions
- R9: Day replay on the dispatcher board, stepping through one day's sailings, notices, reassignments, downtime and checklists in order.
- R10 to R13: Crew page at /crew with shift calendar by day, week and boat, hours against the 40 hour limit with warnings, swap requests with approve or decline saved after reload, and safety checklists that clear or block a sailing and save.
- R14 to R16: Maintenance page at /maintenance with parts inventory and low stock state, stock adjustments saved after reload, work orders that can be created, started and completed, and a downtime calendar that blocks new bookings on an out boat and marks its sailings blocked on the timetable.
- New actions in musemuse.json: replay_day, request_swap, approve_swap, submit_checklist, create_work_order, set_boat_downtime, each with a test in tests/actions.spec.ts.
- R9 to R16 tests added to tests/requirements.spec.ts, and the smoke test now covers the crew and maintenance screens.
Evidence
- Second verify run this round: typecheck, build, start, console and manifest passed, as did most requirement tests.
- After the last fixes, focused Playwright runs passed the previously failing R11 and R13 tests and the full smoke test, including live notice and daily job steps.
- I checked the R16 screenshot: it shows the blocked Dawnlight sailing and the plain out for maintenance error.
- BUILD_NOTES.md documents all of this, including the honest verify status for the round.
Checks found problems, try 2
Smoke test, Requirements
Milestone 3 is built. This round used its two npm run verify runs, so the platform verify is the next full run.
Fixed from the last check
The R11 swap and smoke cancellation failures were gateway rate-limit errors. The shared cache in lib/harbor-server.ts now holds lists for 60 seconds, clears only the list a write changes, and retries reads three times. Cancellation also clears the refunds cache, which fixed a stale finance view.
Milestone 3 additions
- R17: Overdue alerts on the maintenance page and via check_overdue_alerts, listing past-due work orders and boats still out of service after a reload.
- R18 to R22: Finance page at /finance with date, route and season filters, revenue by route and season, saved fuel entries with cost per crossing, refunds linked to booking code and route, CSV export, and four bar charts.
- R23: Passenger assistant on the public site, using Muse Wonder through respondJson in ask_assistant. It answers only from the saved timetable, fares, notices, downtime and booking data, shows "Where this came from" sources, and now shows a source line even when the model returns an empty list.
- R24: "Hand off to a person" saves the conversation as a staff ticket. Staff see and answer tickets on the handoffs screen at /handoffs, saved after a reload.
- musemuse.json now lists 17 actions, each with a test in tests/actions.spec.ts. R17 to R24 each have a test in tests/requirements.spec.ts, and the smoke test covers finance and the assistant.
Evidence
- First verify: typecheck, build, start, console, manifest and all caps checks passed. 38 of 42 tests passed.
- The four failures were fixed and passed in a focused run.
- Second verify: 41 of 42 tests passed. The only failure was R17 matching two saved Ember alerts at once in its own test.
- That assertion now checks the first match, R17 passed in a focused run, and the assistant screenshot shows a grounded answer with its source section.
- BUILD_NOTES.md records all of this, including the honest verify status.
Checks found problems, try 3
Smoke test, caps, Requirements
Checks found problems, try 4
Smoke test, caps, Requirements
Checks found problems, try 5
Smoke test, Requirements

The plan: Harborlight

One calm home for Saltmere ferry bookings, boats, crew, repairs and money.

Can build part of it

Open the public site and view the timetable for 6 invented routes with season fares
Choose a route, date, sailing, seats and whether a vehicle is coming
Check live availability

Won't do: All people, boats, routes, fares and history are invented for the Saltmere Ferry...

See the full plan

Who it's for

Passengers booking Saltmere ferries and the cooperative dispatchers, crew, mechanics and finance staff who run them.

How it works

Open the public site and view the timetable for 6 invented routes with season fares.
Choose a route, date, sailing, seats and whether a vehicle is coming.
Check live availability. If the boat is out for maintenance, see that the sailing cannot be booked and choose another sailing.
Confirm the booking and receive a booking code and total fare.
See the same booking appear on the dispatcher board for its boat and sailing.
Use the booking code in booking lookup to view the trip and any delay, weather or downtime notice.
Ask the passenger assistant about the trip, delay or vehicle rule and get an answer from the saved timetable and notices.
Cancel from booking lookup if needed and see the refund appear in finance reports.

Screens

Public timetable. Shows 6 routes, sailings, season fares, availability and active delay, weather and downtime notices.
Booking. Collects route, date, sailing, seats and vehicle, checks downtime and capacity, and confirms with a booking code.
Booking lookup and cancel. Finds a booking by code, shows notices affecting it and offers cancellation with refund result.
Passenger assistant. Chat panel on the public site answering from saved timetable, notices and booking data, with sources and staff handoff.
Dispatcher board. Live board of 8 boats with sailings, bookings and crew, drag reassignment and notice publishing.
Day replay. Steps through one day of sailings, notices, reassignments and downtime in time order.
Crew calendar. Shows shifts by crew member, hours totals and limit warnings.
Swap requests. Lets crew request swaps and approvers approve or decline with an hours check.
Safety checklists. Pre-sailing checklist that clears or blocks each sailing and saves the result.
Parts inventory. Shows parts, stock levels, low stock warnings and stock adjustments.
Work orders. Creates and tracks maintenance work, due dates, completion and overdue alerts.
Downtime calendar. Shows boats out of service, blocks bookings and lists affected bookings with draft notices.
Finance reports. Revenue by route and season, fuel per crossing, refunds, charts and CSV export.
Staff handoffs. Lists assistant handoff tickets with conversation history for staff to answer inside the product.
Admin roles and audit. Browser role picker for dispatcher, crew, mechanic and finance, plus the full audit log and seed data controls.

What goes in

Text: Route, date, passenger count and vehicle choice for booking. All routes, boats and fares are invented.
Text (optional): A booking code such as HF-2841 for lookup, cancellation and assistant questions about a booking.
Text (optional): Dispatcher drag actions, delay text, weather notice text and replay date.
Text (optional): Crew shift choices, swap requests, approvals and safety checklist answers.
Text (optional): Parts, quantities, work orders, downtime dates, fuel costs and refund records for maintenance and finance.
Text (optional): Free text questions for the passenger assistant and optional booking code for a personal answer.

What comes out

Text: Timetable for 6 invented routes with sailing times, boats, fares by season, seat and vehicle availability and active notices.
Text: Booking confirmation with a lookup code, total fare, sailing details and cancellation and refund result.
Text: Live dispatcher board for 8 boats, crew assignments, notices and a step by step day replay.
Text: Crew calendar, swap decisions, hours warnings and cleared or blocked safety checklists.
Text: Parts inventory, work orders, downtime calendar, blocked sailings and overdue alerts.
Text: Finance totals and charts for revenue by route and season, fuel cost per crossing and refunds.
File: CSV export of the filtered finance report.
Text: Passenger assistant answers with sources from saved data, staff handoff tickets and a complete audit log.

Models

Model	Used for	Why
Muse Wonder	Powers the passenger assistant. It answers only from the timetable, notices and booking data passed to it, explains delays and fares, and decides when to offer a staff handoff.	Needed for grounded chat answers over saved operational data and for clear summaries of delays, replays and finance figures in plain language.

Limits

All people, boats, routes, fares and history are invented for the Saltmere Ferry Cooperative. No real ferry service, payment or external messaging is connected.
No real payment is taken. Booking shows the fare due and records refunds as finance entries, not as money returned by a payment provider.
The product cannot send email, SMS or WhatsApp. When downtime or a delay affects passengers, it shows the notice in booking lookup and the assistant and drafts a notice for staff to send themselves.
People cannot sign in to products yet. Admin roles are a role picker kept in the browser for this suite, not enforced accounts, so role limits show what each role may do but cannot prove identity.
Passenger contact details are not stored in the shared collections. Bookings are tracked by code, seats, vehicle, fare and status so dispatch, maintenance and finance can work from the same record.
The passenger assistant answers only from the timetable, notices and booking data passed to it. If the answer is not in that data, it says so and offers a staff handoff inside the product.
Staff handoff creates a ticket staff can see and answer in the product. It is not a live external help desk or phone call.
Live board changes show in other open browsers within a few seconds, for at most 20 people watching at once and 10 from one network.
Background schedules stop after 14 days with no visit from the owner, until the owner visits again. Draft alerts wait for the owner to confirm and are not sent by the job itself.
Automated and browser tests check the main and cross-part flows, but invented live conditions such as weather are entered by staff rather than read from a real weather service.
Can't do: Provide real sign-in roles for dispatcher, crew, mechanic and finance that prove who a person is.. People cannot sign in to products yet, so real role accounts cannot be enforced.
Can't do: Automatically send external email or text messages to affected passengers to notify them when a boat is taken out.. The product cannot send email, SMS or WhatsApp, so external passenger messages cannot be sent automatically.

From your inspo

The person gave a text-only request for Harborlight, a complete invented operations suite for the fictional Saltmere Ferry Cooperative, with seven connected parts, shared data, testing and a calm harbor at dawn look.

Takes

The complete multi-part operations job: public booking, dispatch, crew, maintenance, finance, passenger help and admin sharing one set of saved data.
The cross-part flow where a booking appears for dispatch, maintenance downtime blocks bookings, and cancellations appear as finance refunds.
The calm harbor at dawn mood, carried into copy, invented place names and any generated imagery, in a responsive phone and desktop layout.

Cost per run: about $0.02 (est.). One passenger assistant run uses about 3,000 input tokens at $4 per million ($0.012) and about 400 output tokens at $20 per million ($0.008), for about $0.02. Booking, dispatch, crew, maintenance, finance and admin flows use saved data and no model call, so a full booking run is about $0.00 to $0.02. Total for the primary booking flow is $0.00, and $0.02 when the assistant is used.

What you asked for 0 of 46 checked and working

R1: Show a public timetable for 6 invented routes with sailing times, boat, duration, seat availability and vehicle availability. Not checked yet Its test passed. The judge hasn't looked yet.
R2: Let a passenger book seats and a vehicle on a chosen sailing, save the booking so it is still there after a reload, and show a booking code. Not checked yet Its test passed. The judge hasn't looked yet.
R3: Show and apply fares by season for every route, seat and vehicle, with the season and total clearly shown before confirming. Not checked yet Its test passed. The judge hasn't looked yet.
R4: Let a passenger enter a booking code and see the booking, sailing, fare, status and any affecting notice. Not checked yet Its test passed. The judge hasn't looked yet.
R5: Let a passenger cancel a booking from lookup, free the seats and vehicle space, save the cancellation after a reload and create a refund record. Not met "R5: passenger cancels from lookup, seats free and refund saved after reload" did not pass.
R6: Show a dispatcher console as a live board of 8 boats with current sailing, crews, status, bookings and next departure. Not checked yet Its test passed. The judge hasn't looked yet.
R7: Let a dispatcher drag a crew member to another boat or sailing to reassign crews and save the change after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R8: Let a dispatcher publish delay and weather notices that immediately update the public timetable, booking lookup and passenger assistant, to notify affected passengers. Not checked yet Its test passed. The judge hasn't looked yet.
R9: Let a dispatcher pick a day in the dispatcher console and replay its sailings, delays, reassignments, downtime and notices in order. Not checked yet Its test passed. The judge hasn't looked yet.
R10: Show each crew member a shift calendar by day, week and boat in the crew app. Not checked yet Its test passed. The judge hasn't looked yet.
R11: Let crew request a shift swap and let an approver approve or decline it, saving the result so it is still there after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R12: Track crew hours, show limits and warn before a shift or approved swap would go over the limit. Not checked yet Its test passed. The judge hasn't looked yet.
R13: Require a safety checklist before each sailing and save whether the sailing is cleared or blocked, still visible after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R14: Show parts inventory with quantities and low stock state and let mechanics adjust stock, saved after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R15: Let mechanics create, update and complete work orders for a boat and part, saved after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R16: Show a boat downtime calendar and block new bookings on sailings for a boat while it is out, saved after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R17: Show overdue alerts for work orders past their due date and for boats still out of service, saved after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R18: Show finance revenue by route and by season with filters for date range. Not checked yet Its test passed. The judge hasn't looked yet.
R19: Show fuel cost per crossing by boat and route from saved fuel entries. Not checked yet Its test passed. The judge hasn't looked yet.
R20: Show refunds from cancelled and downtime affected bookings in finance, linked to the booking code and route. Not checked yet Its test passed. The judge hasn't looked yet.
R21: Let finance export the filtered report as a CSV file. Not checked yet Its test passed. The judge hasn't looked yet.
R22: Show finance charts for revenue by route, revenue by season, fuel per crossing and refunds. Not checked yet Its test passed. The judge hasn't looked yet.
R23: Provide a chat helper on the public site that answers passenger questions from the saved timetable and notices and shows where the answer came from. Not checked yet Its test passed. The judge hasn't looked yet.
R24: Let the chat helper hand off and hands off to a person by creating a staff ticket with the conversation, saved so staff can see and answer it after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R25: Provide real sign-in roles for dispatcher, crew, mechanic and finance that prove who a person is. Can't be done People cannot sign in to products yet, so real role accounts cannot be enforced.
R26: Provide a browser role picker for dispatcher, crew, mechanic and finance that limits which screens and actions each role sees in this suite, kept in the browser as the closest available option and still there after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R27: Keep an audit log of every change, including role, action, item, old value, new value and time, still there after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R28: Provide seed data with at least 90 days of made-up history for sailings, bookings, crew, maintenance, fuel and refunds, still there after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R29: Use one shared saved database for all parts of this operations suite so a booking made on the public site shows on the dispatcher board, still there after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R30: When a boat is taken out for maintenance, block new bookings for its sailings and notify affected passengers by marking affected existing bookings in lookup and the assistant, saved after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R31: Automatically send external email or text messages to affected passengers to notify them when a boat is taken out. Can't be done The product cannot send email, SMS or WhatsApp, so external passenger messages cannot be sent automatically.
R32: As the closest option to notify passengers, create a draft passenger notice for downtime and delays that staff can copy and send themselves, and show it in booking lookup and the assistant, saved after a reload. Not checked yet Its test passed. The judge hasn't looked yet.
R33: Make finance see refunds from cancellations and downtime without re-entering them. Not met "R33: finance sees downtime refunds without re-entering them" did not pass.
R34: Write automated tests for every part and run them, including booking, dispatch, crew, maintenance, finance, assistant and admin, and show the test results in the build record. Not checked yet Its test passed. The judge hasn't looked yet.
R35: Test all the cross-part flows in a browser, including booking to dispatch, maintenance blocking bookings and cancellation to finance refund, and fix what fails before finishing, including anything that fails on phones. Not checked yet Its test passed. The judge hasn't looked yet.
R36: Make the look distinctive and calm, like a harbor at dawn, on phones and desktops across every screen. Not checked yet Its test passed. The judge hasn't looked yet.
R37: Build Harborlight as a complete operations suite for the invented island ferry company Saltmere Ferry Cooperative, so the whole operations product covers booking, dispatch, crew, maintenance, finance, assistant and admin together. Not checked yet Its test passed. The judge hasn't looked yet.
R38: Make clear that all people, boats, routes and numbers are made up for this island company, and label invented numbers as invented wherever sample fares, counts and history appear. Not checked yet Its test passed. The judge hasn't looked yet.
R39: Deliver this as a big multi-part product with all seven parts working together, not as separate disconnected pages, so data flows across the multi-part operations suite end to end. Not checked yet Its test passed. The judge hasn't looked yet.
R40: Build the work in separate part-sized workstreams that correspond to one per part: public booking, dispatcher console, crew app, maintenance tracker, finance reports, passenger assistant and admin, each completed and tested before the whole is joined. Not checked yet Its test passed. The judge hasn't looked yet.
R41: Split the implementation work across subagents, one per part, in the build plan and milestones, with each part owning its screens, actions and tests and integrating through the one shared database. Not checked yet Its test passed. The judge hasn't looked yet.
R42: Take as long as the quality needs by not cutting corners: every part is finished to a usable quality standard, tested, and checked in a browser before it is marked done. Not checked yet Its test passed. The judge hasn't looked yet.
R43: Do the whole thing, not a sketch: deliver the whole product with real saved data, complete flows, empty and error states and cross-part behavior, not a sketch, mock or partial demo. Not met No test ran for it.
R44: Provide clear navigation between public, dispatcher console, crew, maintenance, finance, assistant handoffs and admin, with the current part easy to return from. Not met No test ran for it.
R45: Show helpful empty states before any booking, notice, swap, work order, handoff or audit filtered result exists, with the next action to take. Not met No test ran for it.
R46: Show plain error states when a sailing is full, a boat is down, a checklist is incomplete, hours would be exceeded or a booking code is not found, and let the person try another choice when an action fails. Not met No test ran for it.
R47: Let staff edit and delete or close notices, work orders, inventory entries and draft alerts they no longer need, with each change written to the audit log and saved after a reload. Not met No test ran for it.
R48: Run a daily background check for overdue maintenance and save draft alerts for the owner to confirm, without sending anything externally. Not met No test ran for it.

This build didn't ship.
Stopped by you.
A broken product is never shown as working. Muse Code's notes are in its steps.
Try another muse
1 h 4 m · $16.55 est.

Harborlight

Harborlight

Status

Models in the product

Links

Muse app connector

This product's builds

The plan: Harborlight

Who it's for

How it works

Screens

What goes in

What comes out

Models

Limits

From your inspo

Takes

Harborlight

Harborlight

Status

Models in the product

Links

Muse app connector

This product's builds

Your muse

The plan: Harborlight

Who it's for

How it works

Screens

What goes in

What comes out

Models

Limits

From your inspo

Takes