In 2026, the repo is meant for context, not just code.

The finding lived somewhere the spec could not reach

Discovery happens outside the repo. Interview notes in a doc, a synthesis deck, a spreadsheet of quotes, a thread where the team argued about what any of it meant. Works fine while the work is fresh and everyone still remembers.

Scope time is where it breaks. The person writing the spec needs one line out of all that, the condition customers attached to their yes. They open the folder and find four decks with nearly identical names. The one carrying the caveat was built by a researcher who has since moved to another team.

Nobody deletes the condition. It just never makes the trip from slide fourteen into the document engineers build from. The hole fills with whatever is easy to point at, and this quarter that is an adoption target, so the feature ships default-on with the off switch pulled and somebody writes the word organic on a slide.

What it costs whoever writes the doc

You become an archaeologist. A whole morning goes into rebuilding a decision that was already made and already written down once, and your reconstruction is thinner than the original, because you are working from memory and a chat search.

Then review starts and the questions come. Why default-on? Did we test that? The doc has no answer, and there is no history behind it to check, because the answer was a file attachment. This is a big part of why specs go stale inside a single quarter.

It costs you with the machines too. Coding agents read the repository. A finding that sits in a drive does not exist for them, so the code gets built from the document that survived, caveat missing. When AI doubles what engineering can chew through, the written scope becomes the thing everyone leans on hardest.

• The condition a customer put on saying yes
• The option the team already ruled out, and the reason
• Who agreed to the change, and when
• The wording someone objected to before it shipped

Keep the part that decides things in the repo

specgit makes a GitHub repo behave like a shared drive. A PM opens the spec, edits it, hits save, and the save is a commit. Comments come back as review threads on the pull request. The discovery finding that changes scope goes into the document itself, in the repo, with a commit showing who put it there and when. See how it works.

A Notion page or a Google Doc holds the conversation well. The problem is distance. That file lives in a different system from the code, so the person writing the spec has to go fetch it, and coding agents never will. We compared both cases in Notion versus GitHub and in the Google Docs alternative writeup. Confluence sits in the same spot.

Plain GitHub already solves the location problem, though the interface wants branches, pull requests, and raw markdown from someone whose job is customer interviews. specgit is the front door for those people. More on docs as code without the git homework.

We never keep a copy of your documents or comments. GitHub stays the source of truth, and the narrow exceptions are spelled out on privacy and security. You can try it without signing up, and the free tier does not want a card. Pricing if you want the numbers first.

So the fix here is dull. Put the finding where the spec is, in a file with history, and the argument about default-on happens in a review thread with the customer condition sitting three lines above it. That way the boss in the comic has something to overrule in writing, and the record of it survives the QBR.