Rescue-or-Keep: building the vault zone for Greenhouse
Greenhouse never deletes anything. Vaulting a project is supposed to feel like a positive, reversible act, dormant seeds, not failure, and the daily ritual surfaces one long-dormant item and asks: rescue it, or leave it be. Before this issue, none of that had a UI. You could vault something and it just… sat there. No way to see what was in the vault, no way to pull something back out, and vaulting didn’t even move the item’s files anywhere, so “browse the vault” would have opened an empty folder.
The two decisions
Two things needed settling before I could write code, and both were genuine judgment calls rather than obvious defaults.
First: should vaulting relocate the project’s folder into a real 90-vault/ directory, or just flip a status flag and leave files where they were? I’d have defaulted to leaving them in place, smaller change, less blast radius. But every other status transition in this app (promote, advance a stage, move between stages) already relocates the folder as part of the change. Consistency won, so vaulting now really does move your files into the vault, and rescuing moves them back out to wherever they came from, an active project’s old stage, or the idea folder if it was never promoted.
Second: what does “Keep Vaulted” actually do? My first instinct was call the same vault command again, since re-vaulting an already-vaulted thing sounds like a no-op. It’s not. The daily review picks the single longest-dormant item by sorting on when it was vaulted. Call vault again and you reset that timestamp to right now, which means the item you just chose to leave alone silently vanishes from review for however long the vault-maturity window is. I caught this before writing any code, thankfully, by actually tracing through what “no-op” would mean for the sort order. Keep Vaulted ended up being a purely local decision, a dismissed-this-session flag with no backend call at all. The item comes back tomorrow, since nothing about it actually changed.
What surprised me
The near-miss with “Keep Vaulted” was the most interesting part of this session. It’s the kind of bug that would never show up in a quick manual test, since a single click looks identical whether it re-stamps the timestamp or not, and it would only surface days or weeks later as “why did this thing I kept vaulted never come back up for review.” I wrote it up as its own note, since the shape of the mistake generalizes: any time a “skip” or “dismiss” action considers calling the same command that produced the current state, check whether that command writes a timestamp something else sorts on.
Where it landed
Rescue restores an item to wherever it was, active at its old stage, or back to a fresh idea, and relocates its folder to match. A new vault-browse view lists everything currently dormant, each with its own Rescue button, following the same full-window navigation pattern the project detail view established a few days ago. A “Vault: N items” indicator makes the vault discoverable from the dashboard instead of hiding behind a single review card. All of it verified with unit tests, component tests, an accessibility pass, and a real WebDriver click-through that confirmed the folder actually moved on disk, not just that a database row changed.
Related reading
Seed tray: the ideas that vanished for a week
Capture an idea in Greenhouse and it disappeared entirely until day seven. The fix was a zone with a countdown - and the discipline of not adding a skip button.
Harvest shelf: giving Greenhouse's released items somewhere to land
Releasing a project was write-only: the database stamped a timestamp, a badge branch could never render, and the entire payoff of the pipeline was invisible.
The callback that couldn't say what happened
Fixing one dashboard-refresh bug exposed a second hiding in the same shared component - and a third bug that turned out not to exist at all.