One engineer. One real project. Idea to a shipped v1.0. Every stage runs through the Niha CLI, from the first brainstorm to the fresh-clone test. You ship the product, and you hand us the evidence of how the tool behaved while you built it. Both are judged.
Registration is open now, and that is the only thing to do today. Project details unlock when the build starts on Mon 14 Sep and it runs to Fri 25 Sep, ten working days. Inside that fortnight the phases are a sequence rather than a calendar: a phase finishes when its gate passes, not when a date arrives.
Last round we only scored the report. This round the product counts too, and the moment a product is judged, effort drifts out of the findings and into the product. So the counterweight is a floor, not a weight.
Ship a working product. Visible, satisfying, and easy to over-invest in.
Log what Niha did, reproduce it, fix it or file it. Invisible, and the first thing dropped when the last Friday gets tight.
Fewer than eight verified findings across the programme caps the score at 60/100, however good the product is.
Zero findings from phases 0 to 3 caps the score the same way. Findings that only appear at hardening time were reconstructed from memory, and reconstructed findings do not reproduce.
Findings logged, fixed and merged into the CLI repo score double. Fixing what you find is the fastest way up the rubric.
Seventy-eight steps sounds enormous until you notice what they are. Forty-eight of them are a file you would have written anyway, the rest are decisions you were going to make in your head. Here is the honest arithmetic before you commit to anything.
A planning estimate, not a promise. About an hour a day is the real overhead, and if your project is a slice of client work you were doing anyway, most of the other seven hours were already on your calendar.
Identical for every product. Only the content changes. Every step names the artifact it produces, so completion is checkable from the repository rather than asserted in a status update. A gate stops the work until its artifact exists.
Accessibility work is only skippable for a product with no interface, and none on the list qualifies.
Given as a file to tick, not as prose. Anything missing is visible without anyone asking how it is going. This copy saves in your browser only, for your own tracking.
Six on whether the tool understands the task, eight on what happens over a long session, five on recording discipline. Each one is attached to work you are doing anyway. The only extra cost is writing down what happened, the day it happens.
Every finding uses one format, handed to you at the start rather than asked for at the end. Where you fix the defect yourself, the fix lives in its own branch and PR in the Niha CLI repo, linked from the finding and submitted with your report. That PR is scored on its own criterion, and the finding behind it scores double. Use the composer below and it will open the issue for you, already written up.
The Actual field is terminal output pasted verbatim. It is the entire evidence model in one field, and it carries almost none of your own source code, which is what makes the submission safe to share. A finding whose Actual was retyped from memory is not a finding.
Fill this in while the terminal output is still on your screen. It writes the block for you and opens a prefilled issue on the CLI repository.
needs title, steps and actual outputThe issue lands on the CLI repository with the finding label, ready for you to pick up. Paste the same block into field/findings.md so your report and the issue say the same thing. When you fix it, link the PR in step 3 and set the disposition to FIXED.
A fix is not scored on whether the diff is clever. It is scored on whether someone else can trust it. Four things, and a check on the pull request fails without them, so this is not a matter of anyone remembering to ask.
Put Closes #412 in the body. When the CLI owner merges, GitHub closes the issue itself, the finding is marked resolved against your name, and criterion 6 is scored from the merged pull requests rather than from anything you have to claim.
#412. That number is now the handle for this defect everywhere: your report, your branch, your pull request.field/findings.md the block becomes Disposition: FILED (#412). The issue and the report say the same thing, which is what stops the two drifting apart.fix/F-07-doctor-token. Two clocks, two commit histories.Closes #412 in the body. GitHub then links them, and merging closes the issue on its own.Disposition: FIXED (PR #1234) in your report and paste the link into step 3 of the form. That is what turns one finding into double points plus criterion 6.If you never fix it, stop after step 3. A filed, reproducible issue still counts in full under criterion 2. The fixing is the bonus, not the entry fee.
How the PR counts. Criterion 6, CLI fixes merged, is worth 10 points on its own: defects fixed in the CLI repo with tests, not just reported. Each fixed finding also scores double under criterion 2. A submission with three merged T1 or T2 fixes and nine reproducible findings will outscore a prettier product with none, and that is intended. Merged means reviewed and merged by the CLI owner; you open the PR, they merge it.
An invented but realistic walkthrough of a single submission, from the charter to the score it earned. Nothing here is longer than it needs to be, which is the point: a six-page field report with nine reproducible findings beats a twenty-five page one with three.
Each criterion is scored 0 to 5 against written anchors, then weighted. The weights are the argument: 40 of the 100 points go to the product and its engineering, 45 to what you learned about Niha and whether you fixed it, and 15 to the lifecycle artifacts that prove the design came before the code. The floor sits on top of this and overrides it.
This is the arithmetic judges use, including the floor, bonuses, penalties and the reward band. Try to make it produce a wrong answer: the "great product, no findings" preset is the one to show anyone who plans to skip the field log.
| Mechanism | What it catches |
|---|
Three bands, non-competitive: everyone who reaches a band is rewarded at that band, and several people can land in the same one. The bands are fixed and so are the amounts. A tier may go unawarded: a prize guaranteed to the least-bad submission removes the reason for the best person to push past good enough.
Fresh clone works, eight or more findings reproduce, CLI fixes merged, artifacts dated before the code. Someone else could pick this up tomorrow.
The primary flow runs end to end, the findings floor is cleared, the long-session log is honest. Gaps are named, not hidden.
A real product exists and a real field report exists, and at least one of them is good. Includes submissions capped at 60 by the floor.
No reward, written feedback on every criterion, and an open invitation to the next round. A killed idea at Gate 2 with the evidence that killed it is not a failure here: it earns its bonus and is scored on the field report.
There is no list to choose from. Bring a slice of the client work already on your plate, or an idea of your own, as long as what you ship is something t.a.c can actually use. A demo built to satisfy the rubric is worth less to us than a small tool somebody opens on Monday morning.
When everybody picks their own project, nobody is assigned to exercise a given part of the CLI, and the surfaces we know least about are the ones that need a connected workspace. These are the ones this round exists to reach. Pick a project that touches some of them where you can, and if yours genuinely cannot, say so at the Gate 2 review and we will help you reshape the slice.
Deploying is part of the deliverable, not a nice-to-have. Stand the whole thing up in a real production setup: the application, the database, the environment variables, the seed data, and a build that runs from a clean commit. Free tiers are expected and completely fine, and you do not need to spend anything. Your demo video has to be recorded against the hosted instance, and the live URL goes in step 3 of the form.
Secrets go in the host's environment settings, never in the repository. Watch the free-tier limits: cold starts, build minutes and row counts are all part of the cost readout you report in phase 7.
Five questions, honest answers. You get a route to take, a realistic band to aim at, and the one thing most likely to trip you up. Nothing is sent anywhere, it runs in your browser.
Register today. Come back on Monday once your problem and plan are settled, and once more when you ship. Nothing else is asked of you here: the daily field log lives in the channel, and the artifacts live in your repository.
Use your own work email. We provision your Niha workspace, repository and the pinned CLI version from this.
Before the start date you will get a workspace, an org-owned repository with branch protection, the pinned CLI version, and the templates as files. Two check-ins left, and both are short.
Fill this in once your scope is cut and the plan is settled. Everything here should already exist in your discovery/ and plan/ folders. You can save and come back to edit it.
Links only. Everything you paste here should already exist.
Your project is in. Verification starts with your findings, then a judge clones the repository fresh.