Say no clearly.
Write the refusal in product language and preserve why it matters.
Free developer tool / open source / no AI required
Nope
file
Test what your product must never become.
Positive requirements tell an agent what to add. Nopefile makes the absences that define your product executable: no tracking, no account, no chat thread, no new dependency, no external request.
The missing half of a specification
Software is also shaped by what it refuses.
“Add a share button” is easy to test. “Never turn this private ritual into a social network” usually lives in a conversation until someone—or an agent—optimizes it away.
Nopefile keeps the human reason beside the machine check. The developer owns the boundary. The agent can read it. CI can enforce it.
Make it testable.
Attach checks for paths, text, dependencies, or a returned web page.
Keep it absent.
The agent reads the same contract that local development and CI run.
Local contract builder
Write the red lines.
Nothing entered here leaves your browser. Start with one refusal that would materially change the character, trust, or architecture of your product.
nopefile.json
1 refusal holds the line
One contract / two readers
Human meaning.
Machine evidence.
local / project
$ nopefile explain
# Farsign: product refusals
## The product has no message thread.
Distance should feel lighter, not become a debt.
$ nopefile check
PASS The product has no message thread.
PASS The product does not track people.
PASS A connection never becomes a score.
All 3 refusals still hold.Deliberate limits
Small enough to trust.
No model. No account. No telemetry. No source upload. No attempt to replace tests, a sandbox, secret scanning, accessibility review, or human judgment.
Nopefile does one thing: it makes important absences visible and testable.