Closing the PRD drift found in a code review pass

Greenhouse has a PRD document that predates most of the implementation. It’s the spec I wrote before any code existed, and like any spec that sits next to a codebase for a few months, it started drifting from what the app actually does. The same full-app review that surfaced the invisible harvest shelf flagged four spots where the doc and the code disagreed. This log is about closing those out.

None of these were bugs. They were all places where I’d made a real decision in code and never gone back to update the paragraph that used to describe the open question.

The mirror files never said they’d get overwritten

Greenhouse keeps SQLite as the source of truth for a project’s state, then writes a plain project.md or idea.md file into the project’s folder so the data stays readable even if you never open the app again. The PRD had left open whether edits to that file would get merged back into the database, or whether the database would just win. In practice I built one-way regeneration months ago: every relevant write rewrites the file from scratch. I never wrote that decision down, and worse, the file itself gave no hint that hand-editing it was pointless. So I added a line to the top of both files: Auto-generated by Greenhouse. Edits here will be overwritten. Small change, but it’s the difference between losing an edit silently and knowing not to make it in the first place.

Two parameters that used to be one

The PRD described the seed quota (a nudge toward capturing a starting batch of ideas) and the low-inventory warning (a nudge to capture more once you’re running low) as if they were two separate configurable values. Somewhere along the way I merged them: the low-inventory warning just fires when your workable item count drops below the seed quota. One parameter, two behaviors. The doc hadn’t caught up, so I reworded the low-inventory bullet to say explicitly that its threshold is the seed quota, not something you’d configure on its own.

A rule with no explanation for why it exists

The onboarding wizard walks through Greenhouse’s core rules as a set of cards, each with a one-line reason it exists. There was no card for the vault dormancy timer: a vaulted project quietly comes up for review after 14 days, and until now nothing told the user that was coming. It would just show up one day as a “Rescue or Keep” prompt with no context. I added a fifth card explaining it. That same walkthrough component doubles as a “why these rules?” dialog reachable from the dashboard footer, so the fix shows up in both places for free.

A claim the dashboard doesn’t actually back up

The daily-flow section claimed the dashboard “reflects what’s been done today.” That’s only true for capture. The app tracks whether you logged a new idea today, but it doesn’t track whether you reviewed a mature idea or worked on an active project today, it just shows what’s currently ripe for those actions, regardless of when you last touched them. I reworded the claim to match what the code actually does instead of quietly growing feature debt against a sentence nobody re-read.

Lesson

A PRD that isn’t updated alongside the code stops being documentation and starts being a historical record of what you meant to build. None of these four items were hard to fix once found, the work was just noticing they’d drifted. Worth a periodic pass, especially after any issue that changes behavior without a matching doc edit in the same commit.