Non-goals: the section that stops an agent inventing features

Everything you did not ask for is a thing your agent may decide to build. Writing down what not to build is the cheapest correction available, and almost nobody does it.

Checked against the tools’ own documentation on 17 August 2026.

You asked for a document viewer. You have a document viewer, and it has comments, and reactions on the comments, and an activity feed, and a share modal with four options.

Nobody decided that. It happened one reasonable step at a time, and every step was defensible on its own — which is precisely why it is hard to argue with after the fact.

Why an agent adds things

Not because it is over-eager. Because the set of features you did not forbid is infinite, and a model completing a spec is doing pattern completion on what documents like yours usually contain. Products like the one you described normally have sharing. So sharing appears.

The same mechanism that lets you write four lines and get a working screen is the one that fills in the fifth thing you never mentioned. You cannot have the first without managing the second.

And an agent that asks about everything is useless, so it is calibrated to decide. Your spec is the only thing that shifts where that line sits.

What a non-goal looks like

Not a warning. A closed door, specific enough to be checked against a diff:

## 4. Non-goals (do NOT build)

- No editing tools. This is not Lightroom.
- No public feed, no follower graph.
- No offline access. The viewer requires a connection;
  do not add service workers or cache document content.
- No mobile or desktop clients. Web only.
- No document content storage. Metadata only.

Three things make those work:

• They name the mechanism, not just the feature. “No offline access” invites an agent to add a service worker for performance. “Do not add service workers or cache document content” does not.
• They are absolute. “Keep sharing minimal” is a budget, and a budget is something to spend. “No sharing in v1” is a boundary.
• They give a reason where the reason is not obvious. “This is not Lightroom” costs four words and stops the whole category, including the six editing features nobody listed.

The ones worth writing down first

You cannot enumerate everything you are not building. You do not need to. The non-goals that earn their place are the ones an agent would plausibly add, which is a much shorter list:

• The adjacent product. Whatever the well-known thing in your category does that you are not doing.
• The obvious next feature. If everyone asks “does it also…” in the first conversation, write the answer down.
• The infrastructure you are refusing. Auth, multi-tenancy, real-time, offline-first, a job queue. Each one is a week, and each one is something an agent will cheerfully scaffold because production systems usually have it.
• The thing you tried and rejected. Otherwise it comes back, and you get to have the same argument with a machine that does not remember losing it.

Non-goals are not forever

A non-goal is a decision about this version, and writing one down is what makes changing your mind cheap. “No sharing in v1” moved to phase two is a planned change. Sharing appearing in the codebase because nobody said not to is a surprise, and surprises cost more than decisions.

The corollary is worth stating: when you do decide to build one, delete it from the non-goals in the same commit. A spec that forbids something the code does is a spec the agent has learned to ignore, and it will start ignoring the rest of it too.

Where they go

In the spec, as their own section, near the top — not scattered through the features as caveats. An agent scanning for scope should be able to find the boundary in one place, and so should you, six weeks later, when you cannot remember whether you ruled something out or merely never mentioned it.

The other nine sections, and what each one is for when the reader is a machine.