Updates
- Crates & gears update trackingINFO
- Night stealing change logINFO
- Bug fixes and QoL notesINFO
Grow a Garden 2 Updates
Update topics are staged here until each note has source and verification context.
Update Verification Rules
- No update note is treated as confirmed until the source, date, and affected mechanic are recorded.
- Community-reported changes should stay labeled until they are checked against a reliable source.
- Patch, event, and code notes need different freshness handling before they are promoted into guides.
Updates guide
How Grow a Garden 2 Updates Should Be Tracked
Update pages are freshness-sensitive. A weak update page can mislead players faster than a weak evergreen guide because game systems may change between sessions. This page is built as an update status board first, with source review pending until each note has a date, source, affected mechanic, and verification status.
What belongs in an update note
A useful update note should say what changed, when it changed, which system it affects, and how confident the site is. A code update needs different handling from a pet balance change. A gear update needs different handling from a visual asset change. Putting all of those into one unverified news list makes the page hard to trust.
The MVP starts with tracked topics rather than confirmed patch notes: crates and gears, night stealing changes, and bug fixes or quality-of-life notes. Each row is marked source review pending. That is a placeholder state, but it is honest. The next step is to add sources and move each row into confirmed, community reported, or needs verification.
Separate fact, report, and interpretation
An update page should separate what is known from what players think it means. Fact is the recorded change. Report is what the community is seeing. Interpretation is the site explaining how the change may affect stock, calculator values, pets, gear, defense, codes, or progression. Mixing those layers can make speculation look official.
This structure also helps the rest of the site. If a patch changes a mutation multiplier, the calculator page needs to know. If an update changes night stealing, the defense page needs a revision. If a code expires, the codes page should move the row quickly. The updates page becomes the change log that explains why other tools changed.
Freshness and version context
Freshness is not just a date at the top of the page. Each update entry should include its own checked date or source date, because one old row can sit next to one fresh row. The page should avoid words like new, hot, working, or confirmed unless those labels have evidence. That is why the MVP uses neutral INFO labels.
When the site starts publishing confirmed updates, older rows should either remain useful as history or be moved out of the main decision flow. A stale code update or stale balance note can harm players if it appears current. Clear labels, archive behavior, and internal links to affected tools are the safe path.
How updates should trigger site changes
An update should not stop at the updates page. If a patch changes a seed price, the stock page needs a new source note. If a patch changes a crop value or multiplier, the calculator needs a data revision. If a patch changes night stealing or gear behavior, the defense page needs a visible review. This page should become the reason log for those edits.
That connection is what makes an update board more useful than a short news feed. Players can see not only that something changed, but also which tool or wiki page was affected. It also helps maintainers avoid silent drift, because every important update creates a checklist of pages that must be reviewed.
Minimum fields for confirmed update rows
- Update title written as a specific affected mechanic, not a vague headline.
- Source type and source date.
- Affected page or tool, such as stock, calculator, codes, pets, defense, or comparison.
- Verification status and a short explanation of what changed.
How players should use this page
- Check whether an update is confirmed before changing a play plan.
- Use source review pending rows as watchlist items, not final patch facts.
- Follow internal links to affected tools when a change touches values, defense, pets, or codes.
- Expect old update notes to be archived or rewritten when they stop helping current decisions.
FAQ
Are these confirmed update notes?
Not yet. The current rows are topics waiting for source review, so the page does not present them as official or confirmed patch notes.
Why keep updates if they are pending?
The pending board shows which systems need source checks and gives players a transparent view of what the site is tracking next.
What should happen after an update is verified?
The row should include source, date, affected mechanic, and status, then link to the page that changed because of the update.
Can update pages become stale?
Yes. Update pages should be maintained carefully because old claims can mislead players when mechanics, codes, or event rules change.