This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.
What I Built
The agreement says one English landing page with a contact form. A new message says, "Please add online payments and a French version."
Neither request sounds huge in a chat. Both add work. Before talking about a price, someone has to put the original agreement beside the new message and work out what changed.
I built Scope Desk for that step. It's a small command-line tool for a freelance developer reviewing client requests. You choose the project, enter the agreed scope, and give it a new message. An open-weight Nemotron model drafts three kinds of suggestions: included work, extra work, and things that need clarification. Each suggestion quotes the request it came from. Included work also has to point to an existing scope item.
The result stays a draft. You read it, explicitly approve it, and export a plain-text scope review to edit before sharing. It doesn't set a price, agree to do the work, or send a message to a client.
The potential buyer is a freelancer juggling small fixed-scope jobs. The value would be having the agreement, new requests and review record together when deciding what to discuss with a client. That's a business hypothesis: I haven't had a real customer try it, and nobody has paid for it. The current prototype is free, MIT-licensed, and still needs user feedback.
Demo
Watch or download the 72-second demo.
The video is a labelled text replay of real saved synthetic model results and actual command-line checks. It is not a live screen recording or a new inference run. The approval in the demonstration was scripted; it doesn't establish that a human reviewed the answer.
It shows three development examples:
- Payments and a French version added to the agreed English landing page: two extra-work suggestions.
- A revision to the third blog post, with one revision per post already agreed: included work.
- "Can you improve it?": clarification, because the request doesn't say what to improve.
It also shows an unapproved draft refusing export, an approved review exporting successfully, and a repeated approval after reopening the database returning the saved receipt without duplicating it.
These are three synthetic development probes, not an accuracy benchmark or evidence that it handles every contract correctly.
Code
The project and repository were created on October 13, after this challenge's opening. This is new code, separate from my earlier TheOne projects. Codex assisted the implementation, tests, documentation and demonstration.
Python 3.11 or later and its standard library are enough for the CLI and SQLite storage. The README has the commands for creating a project, analysing a request, reading the draft, approving it and exporting the review. The model call requires your own provider access; inference is not promised to be free.
Eight offline tests use mocked provider responses. The three genuine model calls are documented separately in the synthetic development evidence. The published implementation's CI passed. Keys and private databases are excluded from the repository.
How I Built It
The model used in the actual calls was nvidia/nemotron-3-super-120b-a12b, served by Nebius Token Factory. Each request contains only the selected project's scope and current message. Other projects don't go into that request.
The response has to match a small JSON schema. The application then checks the quotes against the input and the scope references against the selected project. An unknown reference or an incomplete response is rejected. Those checks establish where the words came from; they cannot establish that the model's interpretation is right. That's why the draft still needs review.
I also wanted the record to survive ordinary interruptions. Approval writes a receipt to SQLite. Repeating that approval after reopening the database returns the same receipt. If the agreed scope changes while inference is running, the result is discarded. A stale unapproved draft cannot be approved against a changed scope.
The persistent prototype budget allows ten attempted model calls per database, including failures. A process restart doesn't reset it. The default request is bounded to 900 output tokens and a 45-second timeout. There is no fake-answer fallback when the key is missing or the provider fails.
This is a single-operator prototype. Its database isn't encrypted and it has no multi-user authentication. A review flag is a deliberate action, not proof that someone actually read the text. The exported review still needs editing before anyone uses it with a client.
Why Does Open Innovation Matter?
The open-weight model does the central task: it interprets a request against an agreement. The original application code is open too, so the prompt, validation, review gate and storage can all be inspected and changed.
The model and endpoint are settings rather than assumptions buried in the workflow. That gives me a place to try another compatible model without rewriting how approval or receipts work. A compatible local endpoint is supported by the client, but I haven't tested local inference. All three actual model calls used the hosted service.
That distinction matters here. SQLite keeps the records on the operator's machine, but the selected scope and message still go to the configured provider. This build does not keep all client data offline, and I haven't measured a cost or quality advantage over another model. The useful part of the open approach so far is control over the workflow and the ability to investigate or replace its parts.
The next useful test is a freelancer trying their own messy, ambiguous requests and telling me where the suggestions stop helping. I would do that with their consent and without publishing their client data.
Prize Categories
Overall challenge entry. No partner category is claimed.
Top comments (0)