Changelog

All notable changes to Generous.nz are recorded here, grouped by version. Every deployed build has a version number, a git tag, and an entry below.

Versioning scheme

Versions follow MAJOR.MINOR.PATCH:

• 0.x — pre-launch. Minor bumps mark a completed build phase or major feature set; patches are bug fixes on the current build.
• 1.0.0 — first public launch.
• 1.x+ — post-launch: minor = new features, patch = fixes, major = breaking changes or significant re-architecture.

Each version is tagged in git (v0.2.0) and the current version is kept in package.json. See docs/version-control.md for how to cut a release.

[0.9.371] — 2026-09-16

Docs

• Test runbook Step 4K covers the organisation flow: the save no longer waits for the AI, the verdict is absent from the request immediately and arrives afterwards, a concerning verdict raises an organisation flag, and the badge is never granted automatically. The handoff records that ORGANISATION is no longer exempt from flagging.

[0.9.370] — 2026-09-16

Fixed

• Organisation AI reviews are no longer synchronous, and no longer ignored. Creating or editing an organisation with a charity number awaited the AI review inside the request — the same latency problem fixed for fundraisers — and then nothing acted on the result, because the review actions had no ORGANISATION branch and the flag block explicitly skipped organisations. The verdict was logged and dropped.
  • The pre-check now runs after the response: the deterministic evidence (number format, duplicate claim) is saved immediately and the AI verdict lands on the verification request seconds later, so a slow provider never delays the save.
  • A verdict of review, reject or suspend now raises a moderation flag (organisations included), so a suspicious application appears in the staff queue instead of being filed and forgotten. It is still not an automatic decision — the badge remains a person's call in Admin → Charity verification, and nothing is auto-rejected.
  • The moderation queue now shows organisation flags properly (name, charity number, links to the storefront and to charity verification) instead of labelling them "Flagged" with no context.
• Changing an organisation's charity number re-opens the check. An organisation that was already verified kept its badge after swapping in a different number, and re-saving the same number stacked a duplicate request in the charity queue on every save. Now only a real change opens a new request, and it clears the verified badge until the new number is confirmed.

[0.9.369] — 2026-09-16

Changed

• Moderation queue wording. Two flags could be misread as the AI having already cancelled something: the AI's own "reject"/"suspend" recommendation and the charity-claim flag. Both now say "held for a person, not auto-rejected", so the queue states plainly that the item is waiting for a decision rather than reporting one. Verified on the live build alongside the high-risk hold (a campaign scoring 1.00 stays PENDING_APPROVAL with a CRITICAL flag, its owner is not suspended, and a person releases it).

[0.9.368] — 2026-09-16

Docs

• Test runbook Step 4J covers the charity check end to end (claim opens a request, AI pre-checks, badge withheld until confirmed, rejection removes it, a claim with no number is held, a campaign with no claim is untouched), and the handoff records the invariant: never render a trust badge from isCharity alone.

[0.9.367] — 2026-09-16

Fixed

• The "Registered charity" badge is no longer awarded by a tick box. A campaign could declare itself a charity and the page rendered "✓ Registered charity (CC12345)" straight from that self-declared checkbox — a trust badge backed by nothing, with the number never checked against anything. Our own Charity Verification Policy and help centre both say the badge appears only after a check and a person's confirmation, so the code now matches:
  • claiming charity status on a campaign opens a verification request (VerificationLog), which appears in Admin → Charity verification;
  • the number is checked immediately for CC-number format, a duplicate claim by another organisation, and whether it contradicts the campaign's own organisation's registered number;
  • the AI charity review finally runs — the charity prompt existed but was only ever called for organisation applications, never for campaign claims. Its verdict, score and reasons are attached to the request so confirming is one click. The AI never grants the badge itself: it cannot know a third party's registration status, so a person confirms;
  • until it is confirmed the campaign shows a neutral "charity status: being checked" note — never a trust badge;
  • a claim we can already tell is broken (no number, wrong format, or a number that contradicts the campaign's organisation) is flagged and the campaign waits for a person; if the AI later judges a claim to be impersonation on an already-live campaign, it comes back into review (held, never rejected);
  • confirming or rejecting the claim in Admin → Charity verification is what sets or clears the badge — nothing did that before, so a campaign claim could never actually be verified.
• The campaign form can now declare charity status properly (checkbox + Charities Services number) with copy explaining that the badge follows a check, and the help centre, the Trust badges article and the Charity Verification Policy all describe the same process.

[0.9.366] — 2026-09-16

Docs

• Test runbook Step 4I proves the "never auto-rejected" promise: a worst-case-risk campaign and a prohibited-item campaign must both be held (never rejected, never suspending the account), a clean campaign must still auto-approve, and the public copy must match. The handoff records the invariant and the two removed settings.

[0.9.365] — 2026-09-16

Changed

• Nothing is rejected, cancelled or suspended by a machine. We publicly promise "flagged activity is reviewed by a human — never auto-rejected", and the code did something else: a campaign scoring 0.9+ for fraud was rejected and its owner suspended with no human involved, the AI was set to auto-reject high-risk content and auto-suspend critical accounts, and prohibited-item scan hits were rejected on the spot. That gap is closed — the two behaviours now say the same thing.
  • A 0.9+ fraud score holds the campaign (offline, CRITICAL flag, admin emailed) instead of rejecting it and suspending the account.
  • Prohibited items (weapons, drugs, counterfeit, stolen goods, identity documents, gambling wording) are stopped and held with the reason instead of auto-rejected — the item is never published and the AI can't approve past the flag, so a person decides.
  • The AI keeps the only two things it does well: approving low-risk content, and flagging everything else. It can never reject, cancel or suspend.
  • Admin → AI settings loses the "Auto-reject high risk" and "Auto-suspend critical accounts" toggles, with a note explaining that these are always a person's decision (rejecting/suspending by hand is unchanged — and a rejection still emails the owner with the reason).
• One automatic refusal remains, and the copy now says so. An order that looks fraudulent is refused before payment is taken (verdict "block"), and anything less certain is held for a human before it's fulfilled or paid out. Refusing to take a fraudulent payment isn't a cancellation — no order exists and no money moves — so it stays, and it's described accurately.
• Copy matched to behaviour on the business page, the about page, both referral pages, the help centre, and the privacy policy plus the fundraiser, seller and wholesaler agreements: all now state that automated screening can approve and hold, but never rejects, cancels or suspends.

[0.9.364] — 2026-09-16

Docs

• Test runbook Step 4H covers flagged content waiting for a person (including the clean-campaign control, both games-of-chance cases, the duplicate-flag check and the human-approval path), and the handoff notes the two rules that keep it true: write the flag before scheduling the review, and never add an auto-approve branch that skips the open-flag check.