Neja Ready

The boat is booked. Neja turns scattered messages into a source-linked departure plan.

Comment

The original question

My brother organizes yacht trips. Before a departure, managers search old chats and documents, copy earlier messages and try to remember what was missing last time. He asked if I could make a tool that used previous trips to prepare the next one.

At first I planned a message generator. Then I got stuck on a more basic question: how does it know which message is needed? The old chats contain different dates, missing facts and sometimes different instructions. So the project changed. I started with the departure plan itself.

What is in the demo

Neja Ready reads previous communication and builds a checklist and timeline for the next trip. Every step links back to a source message.

I made three fictional trip histories with 27 messages. There are no real passenger or company chats in the public project.

The demo has two modes. One shows the GPT-5.6 result I saved during development. The other lets judges click through the same workflow with fixed data and repeat the result.

The first mode is called Recorded GPT-5.6 proof. I kept the response as it came from the API. It produced nine preparation steps and preserved all three conflicts I had placed in the data. It also turned five missing fields into three groups of questions.

The second mode is called Synthetic fixture demo. JavaScript checks sources, excerpts, required facts, dates, dependencies and approval state. The supplied fictional answers move the plan from three blocked steps to zero.

Approval only changes the demo state. Neja does not send messages. The last screen says Plan approved · nothing sent.

Building it

Codex wrote most of the code and helped with research, tests, UI work and release checks. My role was to choose the problem, change the product direction, review the results and decide what was ready to release.

I made two GPT-5.6 API calls for the recorded evaluation. Before the first call, Codex and I fixed the test the response had to pass. The first response failed it. I did not repair the JSON by hand because then it would no longer be a clean test. We changed the prompt, and the second response passed the same test.

I changed the provider adapter after recording that result, and I have not validated the new version against the provider yet. For that reason, the public demo replays the saved response. It does not make a new provider call.

The public commit has 79 checks. They cover bad JSON, timeouts, refusals, invented sources, wrong excerpts, undeclared facts and dependency cycles. The local judge path does not need npm install or a build step.

Near the end I found a one-pixel horizontal scroll on mobile. I spent some time finding it, fixed it and repeated the flow at four screen widths. It was a small bug. Once I noticed it, it was very visible.

What I learned

I started the project thinking the generated messages would be the main product. By the end, I cared more about the plan behind them: where each step came from, what was still missing and why the trip was blocked.

The whole project was made quickly. This also meant I had to check many things more than once. A wrong direction can become a working application very fast now.

What I have not tested yet

I have not tested Neja with a real operator yet. The demo data is fictional. The starting question came from my brother's real workflow.

My next step would be a simple test with an organizer. I want to know if reviewing this plan is easier than rebuilding it from old chats. If it is useful, I would add plan editing, version history and a record of why each step changed. Sending or scheduling would come much later.

How to test it

  1. Clone the repository from the Devpost Repository field.
  2. Use Node.js 22 or newer and run npm run verify. There is no install or build step.
  3. Run npm start and open http://127.0.0.1:4173.
  4. Keep Recorded GPT-5.6 proof selected. Click Reconstruct readiness protocol and open the evidence card.
  5. Switch to Synthetic fixture demo, reconstruct again and apply the supplied fictional answers. The state should move from three blockers to zero.
  6. Approve the plan. Check Plan approved · nothing sent, then open a timeline item to see its required facts and source messages.

Built With

  • codex
  • css
  • github-actions
  • gpt-5.6
  • html
  • human-in-the-loop
  • javascript
  • json
  • node.js
  • openai
  • responses-api
  • schema-validation
  • synthetic-data
  • workflow-automation
Share this project:

Updates