Orte & Wohltätigkeitsorganisationen, Live-Zugriff auf CGW und eine leistungsstärkere GardenApp
CoinGarden verknüpft nun in „Orte & Wohltätigkeitsorganisationen“ echte Umweltberichte, Community-Unterstützung und verifizierte Abschlussnachweise. Dieses Update integriert außerdem die bewährte CGW-Mainnet-Erfahrung in das Token-Portal, erweitert die Blumen-Community und die Pflege-Tools und verbessert die Zuverlässigkeit von Wallet, KI und Administration.
Neu
Places & Charities ermöglicht es Nutzern, verschmutzte oder gefährdete Orte mit Fotos und Kartenkoordinaten zu melden, den Fortschritt öffentlich zu verfolgen, Kampagnen mit CGW zu unterstützen, Vorher-/Nachher-Beweise einzureichen und verifizierte Ergebnisse einzusehen.
Jeder eingereichte Beitrag wird einer erneuten KI-gestützten Überprüfung unterzogen. Eindeutige Berichte können direkt veröffentlicht werden, während unklare, doppelte, widersprüchliche oder unsichere Berichte von menschlichen Moderatoren geprüft werden; die KI entscheidet niemals über die Finanzierung oder die CGW-Richtlinien.
Die Umweltleistungen spiegeln nun Berichterstattung, Unterstützung aus der Gemeinde, bestätigte Beiträge, verifizierte Aufräumarbeiten und Umweltprämien in den Bereichen Profil, Leistungen und Verwaltung wider.
Die öffentliche Blumenfreigabe umfasst jetzt detailliertere Blumenkarten, Besitzerbeschreibungen, öffentliche Gärtnerprofile, die Möglichkeit, Followern zu folgen, hervorgehobene Abzeichen, Kopier-/Teilen-Funktionen und kontinuierliches Scrollen zur Entdeckung neuer Blumen.
Garden Plus bietet über die bestehenden Konto- und Zahlungsprozesse die Möglichkeit zum Bezahlvorgang, zur Rechnungsverwaltung, zur Festlegung von Nutzungslimits und zur Erinnerung an die Vertragsverlängerung.
Das Token-Portal unterstützt jetzt die Anmeldung über Google, verknüpfte Wallet-Profile, eine Option zur Signatur des Ledger-Eigentums, gemeinsam genutzte Admin-Belohnungsentwürfe und den direkten Zugriff auf verifizierte CGW-Handels- und Liquiditätsziele.
Verbessert
Das Token-Portal und das Admin-Center lesen die kanonischen Live-Daten des Solana Mainnet CGW-Mints, -Pools, -Balances, -Inhaber, -Transaktionen, -Authorities und -Market-Links anstelle des veralteten Vorstart- oder Platzhalterzustands.
GardenApp bietet direkte Bewässerungsfunktionen, eine übersichtlichere Garten- und Blumenhierarchie, themenbezogene Abonnementvorteile, Homepage-Verknüpfungen, kompakte mobile Karten und nützlichere Profil-Aktivitätsübersichten.
Die Identifizierung und Pflege von Blumen erfolgt mithilfe eines erweiterten, sorgfältig zusammengestellten Pflanzenkatalogs mit geprüften Namen, Pflegehinweisen, Angaben zur Zuverlässigkeit und Herkunft, wobei Korrekturen weiterhin vom Gärtner vorgenommen werden können.
Das Admin Center bietet erweiterte Funktionen für Benutzer-/Inhaltsaktivitäten, Moderation und Finanzierungskontrolle von Orten, Nachweise für Umweltabzeichen, gemeinsame Belohnungsabläufe, Analysen und robustere Übersetzungsprozesse.
Alle drei öffentlichen Websites stellen konsistente, schreibgeschützte Agenten-Erkennungsdokumente und Google Analytics-Messwerte bereit, ohne den Zugriff auf private Kontodaten zu erweitern.
Behoben
Die Signierung von Ledger-Transaktionen auf dem Desktop wurde wiederhergestellt und die Verifizierung für die vom Wallet hinzugefügten Prioritätseinstellungen korrigiert, wobei die exakten Challenge-, Signatur- und Replay-Prüfungen beibehalten wurden. Der Android Mobile Wallet Adapter unterstützt weiterhin die native Anmeldung, und herkömmliche Erweiterungs-Wallets behalten die Nachrichtensignierung bei.
KI-Anfragen nutzen das zentrale, vom Anbieter konfigurierte Gateway mit korrigiertem Timeout und Fallback-Verhalten; die Blumenidentifizierung verwendet niemals ein erfundenes Ergebnis, wenn Anbieter nicht verfügbar sind.
Fotos von öffentlichen Orten werden für anonyme Besucher über Direktlinks geladen, einschließlich älterer, zwischengespeicherter Medien-URLs; temporäre Fehler bei privaten Fotos werden nach der Genehmigung nicht zwischengespeichert, und die Vorschau von Orten in sozialen Netzwerken verwendet das echte Titelbild.
Ortskarten zeigen jetzt auf schmalen Bildschirmen große Fotos, lange Titel, Standorte und Aktionssteuerelemente in separaten, begrenzten Zeilen an; Profil-Impact-Karten verlinken zu Orten und Wohltätigkeitsorganisationen.
Im Rahmen der September-Updates wurden CI, Mainnet-Manifestprüfungen, Token-Daten-Fallbacks, mobile Navigation, Katalogpaginierung, Übersetzungen und die Zuverlässigkeit öffentlicher Seiten verbessert.
Sicherheit
Die Wallet-Authentifizierung verifiziert die vom Server generierte Challenge und die ausgewählte Adresse kryptografisch und verbraucht jede Nonce nur einmal; die nativen SIWS-Felder bleiben unverändert und Ledger-Proofs behalten die strikte Memo-Only-Verifizierung bei. Es wird keine Authentifizierungstransaktion übertragen.
CGW-Beiträge bleiben benutzersigniert und werden erst nach On-Chain-Verifizierung gezählt; Projektauszahlungen und Umweltprämien bleiben explizite Squads-Multisignatur-Operationen ohne anwendungseigenen Signaturschlüssel.
Die Ansichten für öffentliche Orte und Blumen zeigen nur die zulässigen öffentlichen Felder an, sensible Bereiche bleiben bei Bedarf grob dargestellt, und gespeicherte KI-/Anbieter-Anmeldeinformationen bleiben unlesbar und serverseitig.
Dokumente
Produkt-, Architektur-, KI-, Datenbank-, Places & Charities-, Token- und Betriebsdokumentation spiegeln nun die verifizierte Solana-Mainnet-Bereitstellung und das aktuelle Verhalten der ausgelieferten Anwendung wider.
Wiederherstellung der mobilen Navigation und Wallet-Verbindung
Stellt das Website-Menü auf Mobilgeräten wieder her, verbessert die bestehende mobile Wallet-Anbindung und zeigt bereits dem Konto hinzugefügte Wallets an. Die Admin-Katalogseiten passen sich schmalen Bildschirmen an und funktionieren mit korrekter Seitennummerierung. Die aktuelle Dokumentation spiegelt die zweistufige Einführungszeremonie wider; das Hauptnetz ist noch nicht in Betrieb.
Verbessert
Die Token- und Flower-Apps nutzen ihren bestehenden mobilen Konnektor. Bereits verknüpfte Wallets werden angezeigt, ohne dass Nutzer sie erneut hinzufügen müssen; die zusätzlichen Phantom-Browser-Handoff-Schaltflächen wurden entfernt.
Die geschlossene Admin-Navigation ist vom Tastaturfokus ausgeschlossen, und die Menüsteuerung kennzeichnet ihren Bereich.
Behoben
Das Menü der öffentlichen Website ist auf Smartphones sichtbar und lässt sich öffnen; es verfügt über größere Touch-Ziele und kann durch Drücken der Escape-Taste geschlossen werden.
Bei der Anmeldung über die Android-Wallet wird vor der Signieraktion eine vorbereitete Herausforderung abgewartet; bei fehlgeschlagenen Versuchen wird eine neue Herausforderung zur Wiederholung vorbereitet.
Die Seiten des Pflanzenkatalogs im Administrationsbereich nutzen die responsiven Karten, Filter und Tabellen der Konsole; die Katalogpaginierung folgt nun dem angeforderten Offset.
Dokumente
Die aktuellen Richtlinien spiegeln die vom Eigentümer dokumentierte Aufhebung der Upgrade-Sperre wider: Zwei Programme mit Squads Vault 0 als Upgrade-Berechtigung. Ältere Versionshinweise bleiben historische Dokumente.
Der Releaseplan unterscheidet abgeschlossene Anwendungsprüfungen von den noch offenen Prüfungsdetails bezüglich Zeremoniensteuerung und -durchführung. Mit diesem Update wird kein CGW-Mainnet-Start autorisiert.
Zeitschloss bei der Zeremonie, dreifach reproduzierte Builds, Anmeldung über mobile Geldbörse
cgw-timelock erhält eine gültige Mainnet-Identität, eine 11-Fall-LiteSVM-Suite und einen Platz in der Genesis-Sequenz; alle drei Programmbinärdateien werden von zwei Verifizierern und CI beim Zeremonien-Commit 9c6e0f8 byte-für-byte reproduziert; der Mobile Wallet Adapter verknüpft sich unter Android über die native Anmeldung mit Solana; die Seite mit den Administratorrechten zeigt die Programm- und Metadatenberechtigungen live an. Das Zeremonienurteil bleibt NO_GO: Die rechtliche Prüfung wird vom Emittenten ausgesetzt, die operativen Gates O1/O5/O6/O7 und C3 bleiben offen, und es wurde kein mainnet-beta-Schreibvorgang durchgeführt.
Neu
cgw-timelock deklariert die Zeremonieidentität EGu8yPEf…s48qi1M; tests-integration/tests/timelock.rs führt die 11 erforderlichen Fälle gegen die reale Binärdatei aus, einschließlich eines realen BPF-Loader-Upgrades, das über den Timelock-PDA ausgeführt wird.
Die Mainnet-Zeremonie-Tools setzen drei Programme ein: @cgw/chain-config erhält timelockProgram/timelockConfig, verify-mainnet-invariants.mjs stellt sicher, dass die Vesting-/Rewards-Upgrade-Autorität == dem TimelockConfig PDA entspricht (Vault 0 direkt ist ein MISMATCH) und die cgw-timelock-Upgrade-Autorität == Vault 0 entspricht, und die Operatorkonsole, das Launch-Runbook, das Zeremonienpaket und die Genesis-Zeremonie beschreiben die gleiche Sequenz.
build-attestation.mjs deckt alle drei Programme ab und weist Teilattestierungen zurück; Pavel A, Ivan G und CI reproduzieren cgw_vesting.so 84c85be2…, cgw_rewards.so 10ec7188… und cgw_timelock.so 8de82668… bei 9c6e0f8.
Devnet End-to-End-Teamtest: team-vesting-check.mjs (schreibgeschützt; zeigte, dass der einzige Team-Zeitplan nie beansprucht wurde, da sein Begünstigter ein Einwegschlüssel ist), team-claim-devnet.mjs (devnet-Only-Claim mit einem Testschlüsselpaar) und URL-Parameter auf team-test-schedule-tool-gr2.html für einen vom Team kontrollierten Begünstigten.
Mobil: Der Mobile Wallet Adapter registriert sich unter Android und verknüpft sich über die native solana:signIn-Schnittstelle – eine Wallet-Sitzung, die autorisiert und signiert. apps/api sendet eine ungebundene SIWS-Challenge und verifiziert die von der Wallet erstellten signierten Bytes (Domain, Adresse, Statement, Nonce, Request-ID).
Administrator-Token-Berechtigungen: Die Berechtigungen für Programm-Upgrades und Metadaten-Updates werden jetzt live gelesen (ProgramData PDA und Metaplex-Konto), anstatt "Unbekannt" zu melden; die erwartete Berechtigung richtet sich nach dem Manifest (Timelock-Konfigurations-PDA, sofern aufgezeichnet, ansonsten Vault 0).
Behoben
Das Repository ceremony.mjs repository.anchor behauptete das Fehlen einer Mainnet-Programmzuordnung, eine Invariante vor T8; jetzt behauptet es, dass die Zuordnung existiert, mit jeder kompilierten declare_id! übereinstimmt und keine devnet-ID wiederverwendet.
verify-fresh-program-identity.mjs lehnt Wallet-Adressen (Signiererkandidaten, Bereitsteller, Gebührenzahler) ab, die als Programmidentitäten vorgeschlagen wurden.
Die von cgw-rewards generierten Konstanten sind über const-Assertions lasttragend, wodurch der dead_code-Fehler von rustc 1.98 behoben wird; LiteSVM-Fehlercode-Konstanten wurden in beiden Suiten korrigiert; CI speichert die Solana/Anchor-Toolchain im Cache.
Sicherheit
Gemäß T8 §2 wurde die Verwahrung dokumentiert: Alle drei Programmschlüsselpaare befinden sich auf einem BitLocker-verschlüsselten externen Laufwerk mit einer zweiten verschlüsselten Kopie; es wurde kein Schlüsselmaterial übertragen.
Die rechtlichen Hürden G2/G3 und die Hürde O3 zur Unabhängigkeit des Unterzeichners bleiben vom Eigentümer aufgehoben (2026-08-25) und verhindern weiterhin das Urteil; die Seite mit den öffentlichen Dokumenten gibt an, dass derzeit keine Unabhängigkeit des Unterzeichners vorliegt.
Entwickler
Attestierungs-, Invarianten-, Manifest-Konsistenz-, Controller- und HTML-Tool-Guards durchlaufen alle die neuen drei Programmpfade und melden NOT_DEPLOYED; die Operatorkonsole wurde live in Chrome von C:\projects unter c8af8ca verifiziert.
Nicht verifiziert in der Autoren-Sandbox: pnpm typecheck/tests für @cgw/api, @cgw/mobile und @cgw/chain-config sowie ein Gerätedurchlauf des Android-Anmeldevorgangs – CI und ein Telefon sind die Wächter.
Schließung der Lücke im Mainnet-Code (T7-T9, Invarianten-Engine, PREPARE-Tools für Zeremonien)
Alle im Rahmen der Mainnet-Readiness-Prüfung abgeschlossenen Code-Kompilierungspunkte werden geschlossen und die bisherige Prüfung auf Drittanbieterberichte durch eine obligatorische interne Bewertung, Adversarial Testing, zwei unabhängige Build-Reproduktionen, Simulationen und die Festlegung finaler Invarianten ersetzt. Das Ergebnis bleibt „NO_GO“.
Neu
scripts/mainnet/verify-program-authorities.mjs (T7): leitet unabhängig voneinander die ProgramData PDA jedes Produktionsprogramms ab und vergleicht deren aktuelle Upgrade-Berechtigung mit einem vom Betreiber angegebenen Erwartungswert.
scripts/mainnet/verify-fresh-program-identity.mjs + docs/token/CGW_MAINNET_PROGRAM_ID_CEREMONY.md (T8): Verhindert die Wiederverwendung eines devnet/localnet Programmschlüsselpaares als Mainnet-Identität; selbstgetestet.
scripts/mainnet/manifest-transition.mjs + verify-manifest-consistency.mjs (T9): KANDIDAT -> BEREITGESTELLT -> UNABHÄNGIG_VERIFIZIERT -> KANONISCHER Zustandsautomat; die kanonische manifest.ts-Datei wird in keinem Zustand automatisch bearbeitet.
scripts/mainnet/verify-mainnet-invariants.mjs: Einzelbefehl-Engine zur Überprüfung der finalen Invarianten, einschließlich Genesis-Hash, beider Programme, Squads, Mint, Metadaten, aller sechs Vaults, RewardsConfig/VestingConfig PDAs und Readiness-Gate-Querschnittsprüfung; JSON-Ausgabe, Exit-Code 0/1, keine Warnungen als bestanden.
scripts/mainnet/evidence-record.mjs: Standard-Evidence-Record-Schema und Append-Only-Writer für jeden irreversiblen Zeremonienschritt, mit einem Schutz für Feldnamen geheimer Materialien.
scripts/mainnet/prepare-mint-metadata-mainnet.mjs, prepare-vaults-mainnet.mjs, prepare-squads-mainnet.mjs, prepare-rewards-vesting-mainnet.mjs: Nur VORBEREITEN + SIMULIEREN + VERIFIZIEREN, ausschließlich öffentliche Schlüssel (es werden keine privaten Schlüssel geladen), direkt nach dem bewährten devnet Genesis Rehearsal #2 / kanonischen Squads-Erstellungsskript modelliert. Bewusst kein Einreichungspfad, gemäß dem bestehenden Design dieses Repositorys, das keine Ein-Klick-Bereitstellung vorsieht.
scripts/mainnet/signer-ceremony-state.mjs: IDENTIFIED -> OWNERSHIP_PROVEN -> APPOINTED -> INDEPENDENCE_VERIFIED -> RECOVERY_VERIFIED -> CEREMONY_READY Zustandsautomat pro Unterzeichner, Reihenfolge der Operationen erzwungen und selbstgetestet.
scripts/mainnet/authority-transition-matrix.mjs: OBJECT/CURRENT/EXPECTED/STATUS für jede verwaltete Mainnet-Autorität, CURRENT wird immer live gelesen.
scripts/mainnet/verify-transaction-safety.mjs: Statische Sicherheitsprüfung aller prepare-*-mainnet.mjs-Skripte (neuer Blockhash, keine dauerhafte Nonce, kein Broadcast, kein Laden des privaten Schlüssels, simulationsgesteuert, Nachweis außerhalb des Repos).
scripts/mainnet/mainnet-readiness-score.mjs: Nicht-gating-Bereitschaftszusammenfassung für ENGINEERING/CUSTODY/LEGAL/OPERATIONS, die das Ergebnis von ceremony.mjs ausdrücklich niemals überschreibt.
scripts/mainnet/mainnet-rpc-lib.mjs: Gemeinsam genutzte, unabhängige RPC/Manifest/Base58-Primitive, die von jedem neuen Skript darüber wiederverwendet werden.
scripts/mainnet/package.json: isoliert die Abhängigkeiten der neuen PREPARE/VERIFY-Skripte @solana/web3.js, @solana/spl-token, @metaplex-foundation/mpl-token-metadata und @sqds/multisig und spiegelt damit die Isolationslogik von scripts/devnet wider.
docs/token/CGW_DEVNET_MAINNET_GAP_MATRIX.md: die vollständige devnet-zu-Mainnet-Betriebscheckliste für alle 30-Zeremoniefunktionen.
Sicherheit
Die außer Kraft gesetzte Bereitschaftsprüfung G5 und das zugehörige Feld für die Genehmigung der privaten Kontrolle wurden entfernt. Aktuell sind folgende Nachweise obligatorisch: interne Ergebnisse, Adversarial Tests, reproduzierbare SBF/IDL-Hashes von zwei unabhängigen Prüfern, Transaktionssimulation und finale On-Chain-Invarianten.
Fünf bezeugte Eigentumsnachweise für Solflare + Ledger Nano S Plus fördern O4 zu PASS; Unterzeichnerernennung, Unabhängigkeit und Wiederherstellung bleiben separate Hürden.
Entwickler
Die Eigentumsnachweisseite Ledger spiegelt nun die devnet-Tools mit einer Verbindungs- und einer Signierfunktion wider. Solflare + Ledger Nano S Plus erzeugten alle fünf exakten v0-Signaturen; ein anschließender bezeugter Durchlauf lieferte separate Bestätigungsprotokolle für Bildschirmzeugen und Zweitkanal, und die Offline-Verifizierung bestätigte die hardwareseitig signierten Schlüsselkontrollnachweise 5/5 im laufenden Betrieb. Phantom wies dieselbe Nutzlast wie in Transaktionsform zurück, daher empfiehlt die Seite den bewährten Weg Solflare. Terminierung, Unabhängigkeit, Wiederherstellung und endgültige Verwahrungsgenehmigung bleiben separate Schritte.
Jedes neue Skript besteht den node --check; verify-fresh-program-identity.mjs, signer-ceremony-state.mjs und verify-transaction-safety.mjs führen jeweils einen echten Selbsttest/Regressionstest durch und bestehen diesen (nicht nur Syntaxprüfungen).
verify-manifest-consistency.mjs wurde tatsächlich gegen das Live-Repository ausgeführt und meldet korrekt, dass 11/11 Strukturprüfungen bestanden wurden, während mainnet-beta weiterhin NOT_DEPLOYED bleibt.
Die Datei mainnet-readiness-score.mjs wurde tatsächlich ausgeführt und meldet korrekterweise 13/26, ohne das endgültige Ergebnis zu verändern.
Die vollständige pnpm-Testsuite (Lint, Typüberprüfung, Build und Paketprüfung) wurde erfolgreich abgeschlossen. Cargo und Anchor sind auf diesem Host weiterhin nicht verfügbar. Die isolierten Solana Abhängigkeiten werden aus einer Sperrdatei installiert, aber die von ihnen übernommenen Hinweise müssen noch behandelt werden, und die Builder benötigen einen temporären devnet Testlauf.
Dokumente
Der mainnet-beta-Block in packages/chain-config/src/manifest.ts bleibt vollständig null/NOT_DEPLOYED.
Das veraltete Drittanbieter-Engagement-Paket und das zugehörige Gate wurden entfernt. Die Bereiche Recht, Tokenomics, Zeichnungserteilung/-wiederherstellung, Aufbau, Netzwerk, Überwachung und Ausführungsgenehmigung bleiben weiterhin offen – 13 von 26 Bereitschafts-Gates sind noch nicht abgeschlossen.
Das Urteil von ceremony.mjs bleibt bestehen: NO_GO; nichts in dieser Version kann eine mainnet-beta-Transaktion unterzeichnen oder übertragen.
Ermöglicht es der schreibgeschützten localhost-Konsole, einem privaten Controller-Datensatz über einen absoluten serverseitigen Pfad zu folgen, ohne ihn dem Browsercode zugänglich zu machen oder Transaktionen zu aktivieren.
Verbessert
Der Loopback-Dienst akzeptiert --control mit einem vorhandenen absoluten privaten control.json-Pfad und rendert die Beweisprüfungen des Controllers im Zeremonien-Workspace.
Die Übersicht meldet den Status der Anhänge und hält die Vorbereitung so lange unvollständig, bis das Kontrollschema und die Repository-Commit-Bindung erfolgreich abgeschlossen sind.
Sicherheit
Der private Pfad und die Datensatzinhalte bleiben serverseitig; der Browser verfügt weiterhin über keine Upload-, Signier-, Transaktionskonstruktions-, RPC-Schreib- oder Broadcast-Funktionen.
Fügt eine sequentielle Fünf-Wallet-Identifizierungsliste und eine vollständige, vom Controller abgeleitete Zeremonienkarte hinzu, während jede Mainnet-Transaktionsaktion gesperrt bleibt.
Verbessert
Die lokale Mainnet-Konsole behält nun erkannte Ledger-Kandidatenadressen über Kontowechsel und Navigation auf der Zeremonienseite für die Browsersitzung hinweg bei.
Die Übersicht bietet nun eine zwölfstufige Vorbereitungskarte, die jede Startphase mit der entsprechenden Nachweisseite und dem vom Controller ermittelten Status verknüpft.
Sicherheit
Die Sitzungsidentifizierung bleibt von der Verwahrung und Autorisierung getrennt, und es wurden keine Nachrichtensignatur-, Transaktionskonstruktions-, RPC-Schreib- oder Broadcast-Funktionen hinzugefügt, während das Mainnet NO_GO ist.
Erfasst und verifiziert den jeweiligen Kandidaten für die Gebührenzahlung der Squads und erhöht die aktuelle Finanzierung der Zeremonie auf 7 SOL, während die Mainnet-Ausführung weiterhin hinter den anderen Starttoren gesperrt bleibt.
Verbessert
Die lokale Mainnet-Konsole ermittelt und finalisiert nun die beiden Kandidaten für die Zeremonienteilnahme sowie die fünf Kandidaten für die Ledger-Unterzeichnung.
Die Bereitschaft zur Finanzierung weist nun die beobachteten 5 SOL-Einsatzkräfte und 2 SOL-Trupps-Gebührenzahler separat aus, mit einem kombinierten Vorbereitungsstand von 7 SOL.
Sicherheit
Die generierten Zeremoniepakete sind sowohl an geprüfte Kostenträgerkandidaten als auch an abgelehnte Kostenträgerersetzungen gebunden, überschneiden sich nicht untereinander oder mit anderen Unterzeichnern und weisen Salden unterhalb der aktuellen Finanzierungsgrenzen auf.
Erfasst den vom Betreiber festgelegten Mainnet-Bereitstellungskandidaten, überprüft dessen Finanzierung schreibgeschützt in der lokalen Konsole und verstärkt die Zeremonieprüfungen, ohne Schreibvorgänge im Mainnet zu ermöglichen.
Verbessert
Private Zeremoniepakete sind nun an den geprüften Einsatzkandidaten gebunden und lehnen einen Ersatzzahler, eine Überschneidung von Zahlerrolle oder eine kombinierte Finanzierung unterhalb des aktuellen Vorbereitungsbudgets ab.
Die lokale Mainnet-Betreiberkonsole liest nun das Kandidaten-Deployer-Konto und den Kontostand zusammen mit den fünf Ledger-Kandidaten aus, während alle Transaktionsaktionen deaktiviert bleiben.
Sicherheit
Der Kandidatenzahler bleibt getrennt von kanonischen Bereitstellungsadressen, der Verwahrung des Unterzeichners, dem zukünftigen Squads-Gebührenzahler und allen On-Chain-Autorisierungsansprüchen; Mainnet bleibt NOT_DEPLOYED.
Ersetzt das Hochladen von Browserbeweisen durch eine selbstladende Mainnet-Operatorkonsole im devnet-Stil, die automatisch den Status von Repository, Manifest, Netzwerk und Signierer überprüft, während alle Schreibvorgänge gesperrt bleiben.
Neu
Ein reiner Loopback-Lesedienst verifiziert die Mainnet-Identität und alle fünf Kandidatenkonten, während alle genehmigten RPC-Anmeldeinformationen außerhalb des Browsercodes gehalten werden.
Phantom und Solflare können eine verbundene öffentliche Adresse anhand der Kandidatenliste identifizieren, ohne dabei Signatur- oder Transaktionsmethoden offenzulegen.
Verbessert
Alle 13 Mainnet-Seiten öffnen sich nun direkt in die automatischen Netzwerk-, Manifest-, Signierer-, Voraussetzungs-, Blockierer- und Protokollansichten, ohne dass Browser-Datei-Uploads oder ein RPC-Einrichtungsformular erforderlich sind.
Die Seitenstruktur entspricht nun den bewährten devnet-Tools: Hinweis auf eine Sperre, Unterzeichnerfeld, nummerierter Aktionsschritt, Vorschlagsstatus und Aktualisierung mit einem Klick.
Fügt für jeden devnet-Operatordateinamen ein produktionssicheres HTML-Gegenstück hinzu, sowie mainnetspezifische Programm-, Mint-/Vault- und Vesting-Nachweisseiten, die so lange geschlossen bleiben, bis geprüfte Zeremonienachweise vorliegen.
Neu
Der Ordner „Solana mainnet“ enthält nun 13 lokal bereitgestellte Betreiberseiten, die Programme, Squads, Mint/Metadaten/Vault-Genesis, Protokollinitialisierung, Vesting, Lockups und kontrollierte Belohnungsoperationen abdecken.
Jede Seite kann bereinigte Zeremoniensteuerungs-, Vorflug- und Kandidatenmanifestdateien lokal im Browser überprüfen, mit optionaler redigierter, nur auf die Sitzung beschränkter RPC-Identitätsprüfung.
Verbessert
Jeder devnet-HTML-Dateiname hat ein explizites Mainnet-Pendant; GR2- und Disposable-Testseiten geben NOT APPLICABLE an, anstatt zum Kopieren von devnet-Code oder -Adressen aufzufordern.
Ein Regressionsschutz beweist, dass die Seiten keine devnet-Adresse, Wallet-Integration, Signaturbibliothek, Transaktionskonstruktions- oder Broadcast-Funktion enthalten, und die Browservalidierung deckt Desktop- und Smartphone-Breiten ab.
Fügt ein betriebsbereites privates Zeremonienpaket und ein maschinell geprüftes NO-GO-Gate hinzu, das weder signieren noch senden kann, damit die Mainnet-Vorbereitung nicht mit der Startgenehmigung verwechselt werden kann.
Neu
Der Solana-Arbeitsbereich verfügt nun über einen geordneten Mainnet-Zeremonieleitfaden, einen privaten Evidenzpaketgenerator und einen Controller, der alle 27 Bereitschaftsgates sowie bezeugte Rollen, Genehmigungen, Unterzeichnernachweise, geprüfte Build-Hashes, unabhängige RPC-Ansichten, Finanzierung und explizite Autorisierung überprüft.
Verbessert
Ledger-Besitzprobleme müssen nun in ein absolut privates Verzeichnis außerhalb von Git geschrieben werden, um die Unterzeichner- und Verwahrungsdatensätze aus dem Quellcodebaum fernzuhalten.
Der Zeremoniencontroller ist strukturell schreibgeschützt: Er meldet NO-GO, solange die Tore geöffnet sind, und enthält keinen Wallet-, Signierungs-, Bereitstellungs- oder Broadcast-Code.
Bereitschaft der Produktionsunterzeichner und Sicherheitsvorkehrungen für den Mainnet-Start
Erfasst die fünf finanzierten Produktions-Ledger-Kandidaten, ohne die Verwahrung zu übertreiben, fügt das fehlende Signer-Gate zum öffentlichen MiCA-Bericht hinzu und stärkt die Beweisführung, die vor einem Mainnet-Start erforderlich ist.
Verbessert
Treasury, Security, Roadmap und MiCA-Bereitschaft stimmen nun überein: Fünf finanzierte Ledger-Adressen sind die vom Betreiber benannten Produktionskandidaten, während Eigentumsverhältnisse, Unabhängigkeit, Wiederherstellung und formelle Ernennung weiterhin offene Fragen darstellen.
Die Mainnet-Umstellung und die Zeremoniennachweise unterscheiden nun die Signer-Wallets von den zukünftigen Squads Multisig und Vault 0 und erfordern Proof-Hashes, Unabhängigkeitsprüfungen, Wiederherstellungsübungen und separate Bereitstellungsfinanzierungsnachweise.
Jede öffentliche Token-Route wird jetzt während der Produktions-Build-Zeit im CI-Prozess im Browser getestet, einschließlich des vollständigen Crawlings interner Links, des responsiven Überlaufs, der Landmarks und der Laufzeit-Konsolen-/Netzwerkfehler.
Behoben
Die öffentliche MiCA-Bereitschaftstabelle enthält nun den Produktions- und Verwahrungs-Workstream, auf den in der eigenen Startstopp-Zeile verwiesen wird, und veraltete Behauptungen, dass kein Produktionsschlüssel nominiert worden sei, wurden entfernt.
Der Schutz vor dem Auslaufen kanonischer Adressen umfasst nun zusätzlich zu Mint, Programmen und Vaults auch zukünftige Squads Vault 0, Mitgliedsschlüssel und den Metadaten-PDA.
Verweise im Whitepaper verweisen nun auf echte Token-Portal-Routen, routenspezifische strukturierte Daten erben nicht mehr die Homepage-Identität, und die optionale Google-Verlinkung schlägt sicher fehl, wenn keine Produktionsanmeldeinformationen vorliegen.
Die Same-Origin-Wallet-RPC-Grenze wendet nun ein datenschutzwahrendes stündliches Limit pro Besucher an, bevor die dedizierte Solana-Provider-Kapazität in Anspruch genommen wird.
Die Metadaten des CGW Explorers wurden korrigiert, ein Modul für kanonische Identitäten hinzugefügt und jede Admin-Token-Adresse verknüpft.
Der Fehler, dass der Solana Explorer den CGW devnet Token als „Unbekannt“ anzeigte, wurde behoben, indem die Mint durch eine ersetzt wurde, die von Anfang an echte On-Chain-Metadaten enthält. Außerdem wurde eine kanonische Funktion hinzugefügt, die nun jede App zur Token-Identitätsprüfung verwendet, und jede Wallet-/Programmadresse auf den Token-Seiten des Administrators wurde zu einem funktionierenden Explorer-Link.
Neu
@cgw/chain-config now exports getTokenIdentity(cluster) — one function that composes token name/symbol/network/decimals with each cluster's mint/program/metadata deployment state, so no app has to import both the token specification and the deployment manifest and combine their fields by hand.
Behoben
Der Solana Explorer zeigt das CGW devnet Token nicht mehr als „Unbekanntes Token“ / „Kein Symbol“ / „Nicht verifiziert“ an. Ursache: Der ursprünglichen devnet Prägestätte wurde die Prägeberechtigung entzogen, bevor ein On-Chain-Metalplex-Metadatenkonto für sie existierte. Dadurch ist das Hinzufügen von Metadaten dauerhaft unmöglich – es handelt sich nicht um eine Verzögerung bei der Indizierung oder einen fehlenden Registrierungseintrag.
Die kanonische devnet-Münze (Genesis-Probe #2) wurde durch Metadaten ersetzt, die in derselben Transaktion wie die Münzerstellung angehängt wurden, bevor die Münzberechtigung jemals geändert wurde. Neue Münzerstellung, sechs Vaults wurden mit exakten Token-Spezifikationszuweisungen im Umfang von insgesamt 1B ausgestattet, die Münzberechtigung wurde widerrufen und die Berechtigung zur Metadatenaktualisierung an den Multisig des Squads Vault0 übertragen – alles wurde anschließend unabhängig anhand von Live-RPC-Lesevorgängen erneut verifiziert und niemals auf das eigene Protokoll eines Skripts vertraut.
Jede Adresse auf jeder Admin-Token-Seite (Mint, Vaults, Authorities, Squads Multisig/Vault0/Members, Program IDs/Upgrade Authorities, Vesting/Rewards Config/Vault/Beneficiary/Claimant Addresses, Holders' Token-Account/Owner Addresses – etwa 20 Adressen auf 7 Seiten) ist jetzt ein echter Explorer-Link anstelle von einfachem Kurztext.
Entwickler
Die neue Datei identity.test.ts hält die URL des Token-Icons konstant und synchronisiert sie mit der eigentlichen Metadaten-JSON-Datei des Token-Portals, sodass sich die beiden nie wieder unbemerkt voneinander entfernen können.
Sorgt für idempotente Stripe-Checkout- und Webhook-Wiederherstellung, setzt Fotolimits durch, bewahrt die Arbeit bei Planlimits und zeigt nur kostenpflichtige Funktionen an, die tatsächlich verfügbar sind.
Verbessert
Bei der Planlimit-Abfrage bleibt das ausgewählte Foto oder Blumenformular erhalten und es wird auf das Abonnement verlinkt, ohne die Entwurfsseite zu ersetzen.
Die Begrenzungen für Fotos pro Blume werden atomar durchgesetzt, und Garden Plus listet nur Funktionen auf, die ein funktionierendes Produktverhalten aufweisen.
Das Farbblatt wartet nun, bis das Menü vollständig geschlossen ist, und unterstützt Escape, eingeschränkten Tastaturfokus und Fokuswiederherstellung.
Behoben
Stripe Checkout verwendet jetzt eine dauerhafte Kaufabsicht und einen bestehenden Stripe-Kunden wieder, wodurch doppelte gleichzeitige Abonnementsitzungen vermieden werden.
Unterbrochene und fehlerhafte Stripe-Webhooks können sicher wiederhergestellt werden, ohne dass die Berechtigung zu früh als erteilt markiert wird.
Rückleitungslinks im Checkout-Prozess zeigen erst dann eine erfolgreiche Zahlung an, wenn der Server den aktiven Zugriff auf den Stripe-basierten Garden Plus-Dienst bestätigt hat.
Die monatlichen und jährlichen Einstellungen verfügen nun über einen klar ausgewählten Status, und personalisierte Discover-Caches werden beim Abmelden gelöscht.
Zahlungshistorie des Administrators, Behebung eines Problems mit Abonnementkarten und Absicherung von Stripe-Webhooks
Die Admin-Abonnementkarte zeigt nun die vollständige Zahlungshistorie eines Benutzers an, ein Fehler, der dazu führte, dass unabhängig vom tatsächlichen Abonnementstatus immer „Nicht verfügbar“ gemeldet wurde, wurde behoben, und der Stripe-Zahlungs-Webhook ist nun ratenbegrenzt, um Missbrauch zu verhindern.
Neu
Admin Center: Die Abonnementkarte eines Benutzers zeigt nun seine vollständige Zahlungshistorie an – jede Bestellung (Status, Zahlungsmethode, Betrag, Datum) mit den zugehörigen Ereignissen sowie Ereignisse auf Abonnementebene wie Verlängerungen, die nicht an eine einzelne Bestellung gebunden sind.
Verbessert
Der Stripe-Zahlungs-Webhook-Endpunkt ist nun pro Verbindungsadresse ratenbegrenzt, womit die für das Abonnement-/Abrechnungssystem geplante Sicherheitsverbesserung abgeschlossen ist.
Behoben
Admin-Center: Die Abonnementkarte eines Benutzers wurde bisher immer als „Nicht verfügbar“ angezeigt, unabhängig von seinem tatsächlichen Tarif, Status oder seiner Nutzung – obwohl die Gewährung und der Entzug von kostenlosem Zugriff stets einwandfrei funktionierten. Jetzt werden korrekte Live-Daten angezeigt.
Gastzugang, Gartenverwaltung, Zeitleiste der Blumenfotos und Übersetzungszuverlässigkeit
Abgemeldete Besucher können nun den Abzeichenkatalog und das lokale Wetter sehen, Ihr Profil verlinkt direkt zu Ihren Gärten/Blumen/Abzeichen, Gärten können sicher mit oder ohne Blumen gelöscht werden, Blumen unterstützen jetzt eine vollständige Foto-Timeline mit Bildunterschriften, und der Fehler, dass die Seite „Admin-Übersetzungen“ bei 0% hängen blieb, wurde behoben.
Neu
Ausgeloggte Besucher können den vollständigen Katalog der Beitragsabzeichen und die grobe lokale Wetterlage einsehen, wobei anstelle einer harten Wand eine thematische Anmeldeaufforderung angezeigt wird.
Ein dauerhafter Eintrag „App installieren“ in der mobilen Seitenleiste mit themenspezifischen iOS-Anweisungen, falls die Plattform keine native Installationsaufforderung bietet.
Die Gartenlöschung bietet nun zwei explizite, klar erläuterte Optionen: entweder nur den Garten löschen (Blumen bleiben erhalten, werden aber keinem anderen Garten zugewiesen) oder den Garten und alle darin befindlichen Blumen löschen, wobei für die zerstörende Option eine stärkere zweite Bestätigung erforderlich ist.
Ein neuer Abschnitt „Blumen ohne Garten“ mit echter Seitennummerierung sowie eine „In den Garten“-Aktion.
Flowers unterstützt jetzt eine vollständige Foto-Timeline: mehrere Fotos pro Blume, chronologisch geordnet, jedes mit einer optionalen Bildunterschrift und einem einstellbaren Titelbild sowie sicherer Löschung einzelner Bilder.
Verbessert
Die Profilseite wurde neu angeordnet, sodass Erfolge, Gärten, Blumen und Abzeichen als erstes angezeigt werden, wobei jedes dieser Elemente mit einer eigenen Seite verlinkt ist.
Die Meldung über einen Fehlalarm in der Überprüfungswarteschlange der Admin-KI, dass auf der Seite möglicherweise ein Preis oder ein Sonderangebot angegeben sei, wurde überprüft und für ungültig erklärt.
Auf den Seiten „Admin-Übersicht“, „Token-Transaktionen“ und „Token-Inhaber“ wird nicht mehr fälschlicherweise „keine CGW-Prägung vorhanden“ angezeigt, wenn die tatsächliche Ursache ein vorübergehender RPC-Ausfall ist.
Behoben
Die Seite „Admin-Übersetzungen“ zeigt nun keine Sprachen mehr dauerhaft mit 0%-Abdeckung an. Eine Übersetzung, die gerade bearbeitet wurde, als die zugehörige Worker-Instanz neu gestartet wurde, wird nun automatisch wiederholt, anstatt dauerhaft hängen zu bleiben. Die Schaltfläche „Fehler wiederholen“ verschlimmert die Situation einer feststeckenden Übersetzung nicht mehr.
Ein fehlender Übersetzungs-API-Schlüssel ist nun ein klarer, umsetzbarer Status anstatt einer stillen, unerklärlichen Lücke in der Abdeckung.
Wetterabhängige Pflanzenpflege, administrative Zuverlässigkeit und Solana RPC-Härtung
GardenApp warnt jetzt, wenn eine reale Wettervorhersage eine Ihrer eigenen Blumen Frost- oder Hitzerisiken aussetzt, die Wetterdaten werden stündlich über einen gemeinsamen Cache aktualisiert anstatt alle sechs Stunden, und es wurden mehrere Administrations-/Zuverlässigkeitsprobleme auf der gesamten Plattform behoben.
Neu
Die Pflegeempfehlungen für Blumen beinhalten jetzt eine Echtzeit-Wetterwarnung (Frostgefahr, Hitzestress oder Hinweis zum Gießen bei Starkregen), die auf Ihrer aktuellen Wettervorhersage und den Eigenschaften der jeweiligen Blumenart basiert – dies ist lediglich eine Empfehlung und stellt niemals eine Aussage zur Toxizität oder medizinischen Wirksamkeit dar.
Verbessert
Die Wetterdaten werden jetzt stündlich statt alle sechs Stunden aktualisiert, wobei ein einziger Anruf des Anbieters von allen Nutzern im selben Gebiet gemeinsam genutzt wird, anstatt dass jeder Nutzer einen eigenen Anruf erhält.
Der Ortsname der Wetterkarte wiederholt nicht mehr die Stadt als eigene Region („Plovdiv, Plovdiv“), sondern zeigt nun immer das Land an.
Auf der Seite „Admin AI Runs“ wird ein Lauf, der keinen Modellaufruf durchgeführt hat, eindeutig gekennzeichnet und kann nach Auslöser gefiltert werden.
Auf der Admin-Statusseite wird ein beeinträchtigter Status aufgrund eines nicht erreichbaren Solana-RPC-Servers erläutert, anstatt fünf grüne Häkchen ohne weitere Erklärung anzuzeigen.
Behoben
Die Seite „Admin-Abzeichen“ enthält nicht mehr 404s.
Die Belohnungs- und Vesting-Seiten des öffentlichen Token-Portals verwenden nun dieselbe dedizierte Solana-RPC-Konfiguration wie der Rest der Plattform, anstatt stillschweigend auf einen anderen Endpunkt zurückzugreifen.
Ein Ausfall der Autovervollständigung von Orten wird nun als Fehler gemeldet, anstatt als „Keine Ergebnisse gefunden“.
Zwei interne Fehlkonfigurationen (ein fehlendes internes API-Token, eine fehlende native Anmeldekonfiguration) werden nun als Ausnahmen protokolliert, anstatt stillschweigend fehlzuschlagen.
Das Token-Portal verfügt nun über eine Fehlergrenze, sodass ein Seitenabsturz dort für die Bediener sichtbar ist, anstatt nur eine einfache Standardfehlerseite anzuzeigen.
GardenApp lässt sich jetzt auf Anfrage ins Bulgarische, Spanische, Deutsche und Französische übersetzen, ermöglicht es dem Gartenbesitzer, seinen tatsächlichen Standort mit Google Places zu suchen und zeigt die Pollenbelastung für diesen Standort an.
Neu
Die Benutzeroberfläche von GardenApp kann in Bulgarisch, Spanisch, Deutsch oder Französisch angezeigt werden, bei Bedarf übersetzt und zwischengespeichert werden, wobei während der Übersetzung sofort eine englische Fallback-Version verfügbar ist.
Der Standort eines Gartens kann nun über die Google Places-Autovervollständigung gesucht und ausgewählt werden, anstatt nur durch manuelle Eingabe.
Bei einem Garten mit ausgewähltem Standort werden auf der Detailseite die Pollenkonzentrationen (Gras/Bäume/Unkraut) in der Umgebung angezeigt.
Admin Center: Eine neue Übersetzungsseite zeigt die Cache-Abdeckung pro Sprache an und ermöglicht es dem Operator, den Cache einer Sprache zu invalidieren oder fehlgeschlagene Übersetzungen erneut zu versuchen.
Verbessert
Das Admin Center meldet, ob die drei optionalen Google-Integrationen (Übersetzung, Orte, Pollen) konfiguriert sind, ohne dabei jemals den Schlüssel preiszugeben.
Das lokale Wettersystem erhält den groben Bereich des Benutzers während eines vorhergesagten Ausfalls aufrecht und kann über einen unabhängigen Ersatzanbieter wiederhergestellt werden.
Verbessert
Bei geplanten wetterbedingten Ausfällen werden nun datenschutzkonforme Kategorien gemeldet, sodass Betreiber Timeout-, Netzwerk-, Provider-Reaktions- und Persistenzausfälle unterscheiden können, ohne Benutzer- oder Standortdaten zu protokollieren.
Der Administrator trennt nun die Aktualisierungszeit des Standorts von der Zeit der letzten erfolgreichen Wettervorhersageaktualisierung.
Behoben
GardenApp blendet eine bereits gespeicherte ungefähre Position nicht mehr aus, wenn die erste Aktualisierung der Wettervorhersage fehlschlägt.
Wenn Open-Meteo nicht verfügbar ist, greift die Wetteraktualisierung auf MET Norway zurück und gibt dem mobilen Proxy genügend Zeit, beide begrenzten Versuche abzuschließen.
Die lokale Wetter-App liefert nun auch dann noch eine ansonsten brauchbare Vorhersage, wenn der Anbieter eine optionale Metrik weglässt, und die App erfasst ihren datenschutzfreundlichen Cloudflare-Standortkontext bereits früher bei jeder Aktualisierung.
Verbessert
Bei wetterbedingten Ausfällen wird nun eine begrenzte, datenschutzkonforme Serverdiagnose und ein Antwortsignal (erkannt/nicht verfügbar) ausgegeben, ohne dass eine IP-Adresse, Koordinaten oder private Standortdaten offengelegt werden.
Behoben
GardenApp verwirft nicht mehr die gesamte lokale Wettervorhersage, nur weil ein optionaler Wetterwert fehlt oder nicht angegeben ist.
Die Wetteraktualisierung erfasst den groben Anfrage-Standortkontext von Cloudflare vor der Authentifizierung und verringert so die Wahrscheinlichkeit, dass der Edge-Kontext über eine asynchrone Grenze hinweg verloren geht.
Öffentliches Blumenaustauschen und die Gemeinschaft folgen
Flower-Links sind jetzt für alle verfügbar und bieten native Funktionen zum Teilen, Kopieren von Links, Erstellen von Profilen, Hervorhebungsabzeichen und die Möglichkeit, der Community zu folgen. Die Wetterdaten werden nach einem Neuladen ebenfalls problemlos wiederhergestellt.
Neu
Kopieren oder teilen Sie den öffentlichen Link einer Blume mit ihrem Namen aus den Blumenprofilen und der Entdecken-App.
Folgen Sie den Züchtern der Community und sehen Sie sich deren Followerzahlen sowie die von ihnen verliehenen Auszeichnungen an.
Behoben
QR-Codes öffnen nun die öffentliche Community-Blume anstatt einer Seite, die nur dem Eigentümer vorbehalten ist.
Nicht verfügbare Wetterdaten werden nicht mehr zwischengespeichert, und bei jedem Neuladen wird der aktuelle ungefähre IP-Standort erneut überprüft.
Die Verknüpfung für Erinnerungen verwendet nun ein leicht erkennbares Glockensymbol.
Sicherheit
Öffentliche Freigaben und Follows verwenden öffentliche Beitragskennungen; private Blumen-, Garten-, Pflege-, Erinnerungs- und Kontokennungen bleiben außerhalb der freigegebenen Links.
Die Open CoinGarden Browser-Apps erkennen nun jeden neu bereitgestellten Build und wechseln automatisch sicher darauf, während sie auf den Abschluss aktiver Speichervorgänge und Wallet-Bestätigungen warten.
Verbessert
Geöffnete Browser-Tabs werden automatisch auf eine stabile, neu bereitgestellte Version aktualisiert.
Aktualisierungen warten auf aktive Formulare, Speicherstände, Wallet-Signaturen und Ansprüche, wobei die bestehende manuelle Aktualisierungskontrolle als Ausweichmöglichkeit beibehalten wird.
Behoben
Code-Deployments werden anhand der unveränderlichen Commit-Identität erkannt, selbst wenn sich die für den Benutzer sichtbare Versionsnummer nicht ändert.
Eine einmalige Schutzmaßnahme pro Build und die Aktivierung von Service-Workern verhindern wiederholtes Neuladen oder veraltete PWA-Shells.
Die Blumenidentifizierung zeigt nie wieder ein Platzhalterergebnis an.
Die Blumenidentifizierung greift nicht mehr auf ein Platzhalterergebnis zurück, wenn die KI kurzzeitig nicht verfügbar ist. Kann die Pflanze momentan nicht eindeutig identifiziert werden, erscheint die Meldung „Diese Pflanze konnte nicht identifiziert werden“ mit einem Button „Erneut versuchen“ – niemals eine zufällige Antwort anstelle einer echten. Dies gilt für die Web-App, die mobile App und die native iOS-/Android-App, sowohl für angemeldete Benutzer als auch für Gäste.
Verbessert
Native App: Der Bildschirm „Identifizieren“ zeigt jetzt den Namen der Pflanze, den wissenschaftlichen Namen, die Konfidenz und alternative Übereinstimmungen in einem übersichtlichen Layout an, anstatt eines rein technischen Ergebnisses.
Behoben
Die Blumenbestimmung (für angemeldete Nutzer, Gäste und die native App) liefert nun kein Platzhalterergebnis mehr, wenn der KI-Dienst nicht verfügbar ist. Stattdessen wird eine klare, verständliche Meldung und ein funktionierender „Erneut versuchen“-Button angezeigt.
Der tägliche Freibetrag für die Identifizierung eines Gastes wird nicht mehr verbraucht, wenn keine Identifizierung möglich ist – der Versuch wird automatisch erstattet.
Entwickler
Der letzte Produktionscodepfad, der ein gefälschtes Identifikationsergebnis liefern konnte, wurde entfernt; der während der Entwicklung verwendete Mock-Provider existiert jetzt nur noch in der Testsuite.
Es wurden automatisierte Tests hinzugefügt, die den Quellcode der mobilen und nativen App nach der alten Platzhalter-Ergebniskopie durchsuchen, damit diese nicht unbemerkt wieder auftauchen kann.
Die KI-/Identifizierungsdokumentation wurde entsprechend diesem Verhalten neu geschrieben.
Behoben: Die Whitepaper-Seite konnte nicht geladen werden.
Es wurde ein Fehler behoben, der dazu führen konnte, dass die Whitepaper-Seite des Token-Portals aufgrund eines Serverfehlers nicht geladen wurde. Der Seiteninhalt ist nun direkt in die Anwendung eingebunden, anstatt beim Seitenaufruf von der Festplatte geladen zu werden. Dies ist zuverlässiger und beschleunigt die Ladezeit.
Behoben
Token-Portal: Die Whitepaper-Seite (/whitepaper) lädt nun nicht mehr sporadisch mit einem Serverfehler. Ihr Inhalt wird jetzt beim Kompilieren der Anwendung in diese eingebunden, anstatt erst bei der Anfrage aus einer Datei gelesen zu werden. Dadurch lädt die Seite auch etwas schneller.
Behoben: Blumenidentifizierung schlug aufgrund eines Verbindungsfehlers fehl.
Es wurde ein Fehler behoben, bei dem die Identifizierung einer Blume mit der Meldung "Wir konnten uns momentan nicht mit CoinGarden verbinden" fehlschlagen konnte, obwohl die Identifizierung selbst tatsächlich erfolgreich war – die App gab auf und zeigte einen Fehler an, bevor eine normale, etwas langsamere KI-Antwort erfolgen konnte.
Behoben
Die Blumenidentifizierung (sowohl für angemeldete als auch für Gäste) schlägt nun nicht mehr mit einem Verbindungsfehler fehl, wenn die KI in normaler Geschwindigkeit antwortet. Das interne Anfrage-Timeout der App war kürzer als die Zeit, die eine tatsächliche Identifizierung dauern kann, sodass ein erfolgreiches Ergebnis manchmal verworfen und dem Nutzer als Fehler angezeigt wurde.
Solana-Programmkompilierungsfehler und ein Fehler bei der Tresorverfolgung wurden behoben.
Drei echte Kompilierungsfehler in den On-Chain-Vesting- und Rewards-Programmen, die durch eine nicht verfolgte Abhängigkeitsversion verursacht wurden, wurden behoben. Außerdem wurde ein Fehler behoben, der es zwei der sechs Vaults von CGW ermöglicht hätte, stillschweigend eine verfolgte Adresse gemeinsam zu nutzen.
Behoben
Die On-Chain-Programme cgw-vesting und cgw-rewards konnten nicht mit der tatsächlich verwendeten Anchor-Lang-Bibliotheksversion (1.1.2 statt der vorgesehenen 1.0.2 – für diesen Workspace war nie eine Sperrdatei hinterlegt worden) kompiliert werden. Die drei daraus resultierenden API-Fehler wurden behoben und eine Sperrdatei hinterlegt, um ein erneutes Auftreten dieses Fehlers zu verhindern.
Die Bereitstellungsverfolgung von CGW umfasste bisher nur einen Adressplatz für zwei separate Tresore (den Liquiditäts-Tresor und den Community-Tresor, jeweils mit einer separaten 5%-Zuteilung gemäß der Token-Spezifikation). Jeder Tresor hat nun seinen eigenen verfolgten Platz, sodass bei einer tatsächlichen Bereitstellung niemals der Saldo des einen Tresors fälschlicherweise als der des anderen gelesen werden kann.
Entwickler
Es wurde überprüft, ob die On-Chain-Programme in dieser Umgebung fehlerfrei kompilieren und linten (cargo check, cargo clippy mit Warnungen als Fehlern); der vollständige On-Chain-Build/Deploy bleibt aufgrund des verfügbaren Speicherplatzes dieser Sandbox blockiert, der separat verfolgt wird.
Verknüpfung des Google-Kontos im Token-Portal und Behebung eines Problems mit der Wallet-Verbindung
Auf der Profilseite des Token-Portals kann nun optional ein Google-Konto als Backup-Identität mit Ihrer Wallet verknüpft werden. Außerdem wurde ein Fehler behoben, der dazu führte, dass der Wallet-Verbindungsvorgang mit der Meldung „Keine Wallet verbunden.“ fehlschlug, nachdem bereits eine echte Wallet verbunden war.
Neu
Token-Portal: Der Google-Bereich auf der Profilseite funktioniert jetzt – melden Sie sich mit Google an und verknüpfen Sie Ihr Konto optional als Backup-Identität mit Ihrem Wallet-Profil. Die Verknüpfung kann später wieder aufgehoben werden. Die Wallet-Anmeldung bleibt vollständig unabhängig und erfordert niemals Google.
Behoben
Token Portal: Beim Verbinden einer Wallet im Modal „Wallet verbinden“ wird nicht mehr fälschlicherweise „Keine Wallet verbunden.“ angezeigt, unmittelbar nachdem die Wallet-Erweiterung tatsächlich verbunden wurde.
Eine übersichtlichere Benutzeroberfläche, eine intelligentere KI-Modellauswahl und die Grundlage für native Apps
Eine Reihe von UI- und Textkorrekturen im Admin Center und Token Portal, eine neu gestaltete mobile Infoseite, die die aktuelle App tatsächlich beschreibt, eine durchsuchbare Modellauswahl zur Bestimmung des KI-Modells, das jeden Assistenten antreibt, und das erste funktionierende Gerüst nativer iOS/Android-Apps – noch nicht zur Installation verfügbar, aber die Anmelde- und Kernbildschirme laufen jetzt vollständig auf den echten Servern von CoinGarden.
Neu
Admin Center: Die Auswahl des KI-Modells für einen Assistenten erfolgt nun über eine durchsuchbare Liste, gruppiert nach Kompatibilität und Verifizierung, Verifizierungsbedarf oder Inkompatibilität – anstatt über ein einziges langes Dropdown-Menü ohne Erklärung.
Mobile App: Die „Über uns“-Seite wurde neu geschrieben und beschreibt nun die aktuellen Funktionen der App (Pflanzenpflege, Identifizierung, Abzeichen, Token-Portal) anstelle veralteter Funktionsbeschreibungen.
Die erste funktionsfähige Version der nativen iOS/Android-Apps von CoinGarden existiert als interne Entwicklungsversion: Mit Google anmelden, Gärten und Blumen ansehen und Pflanzen per Kamera identifizieren. Sie ist noch nicht im App Store oder Play Store verfügbar.
Verbessert
Mobile-App: Ihre Profilseite zeigt jetzt Ihre tatsächlichen Garten-, Blumen- und Abzeichenanzahlen anstelle eines Platzhalters an.
Admin Center und Token-Portal: Diverse Layout- und Textkorrekturen, darunter ein Diagramm des Token-Portals, das auf schmaleren Bildschirmen überlappen könnte.
Sicherheit
Es wurde eine Lücke geschlossen, bei der durch das Zuordnen eines KI-Modells zu einem Assistenten nicht überprüft wurde, ob das Modell tatsächlich die Anforderungen des Assistenten erfüllte (z. B. Bilderkennung zur Pflanzenidentifizierung), so wie es bereits der Hauptkonfigurationsbildschirm tat.
Entwickler
Die Server von CoinGarden unterstützen nun eine echte, widerrufbare Anmeldesitzung für native Apps, die vom Anmeldesystem der Website getrennt ist, da eine Telefon-App keinen eigenen Server besitzt, der ein gemeinsames Geheimnis wie die Website speichert.
Die Token-Seiten im Admin Center lesen jetzt den tatsächlichen Status von CGW direkt von Solana anstatt eines statischen Platzhalters und aktualisieren sich automatisch, solange sie geöffnet sind – sie zeigen die Wahrheit, wie sie heute ist: CGW ist zur Implementierung freigegeben, aber noch nicht auf einem Cluster bereitgestellt.
Neu
Die Token-Seiten im Admin Center (Übersicht, Inhaber, Treasury, Sicherheit, Transaktionen) lesen nun den aktuellen Bereitstellungsstatus von CGW, Prägedetails, Angebot, Tresorguthaben und Präge-/Einfrierungsberechtigungen direkt von Solana über eine schreibgeschützte, serverseitige RPC-Verbindung – niemals über den Browser.
Jede Token-Seite aktualisiert sich nun automatisch, solange sie geöffnet ist (5s auf Token-Seiten, 10-15s in der globalen Shell), pausiert, solange der Tab ausgeblendet ist, aktualisiert sich sofort nach dem Fokussieren und wird nach wiederholten fehlgeschlagenen Lesevorgängen automatisch zurückgesetzt – ehrlich als Polling bezeichnet, niemals als Live-Socket-Verbindung.
Eine eindeutige Fünf-Zustands-Anzeige des Bereitstellungsstatus (nicht bereitgestellt, konfiguriert, aber nicht erreichbar, konfiguriert, aber das Konto fehlt, bereitgestellt und fehlerfrei oder bereitgestellt mit einer Abweichung von der genehmigten Spezifikation) ersetzt den alten Platzhalter „immer falsch“.
Verbessert
Inhaber- und Transaktionszahlen werden nun immer mit den tatsächlich ausgelesenen Daten gekennzeichnet – „Top-Token-Konten“ anstelle einer impliziten vollständigen Inhaberliste und ein ehrliches „Nicht verfügbar über konfigurierte RPC-Verbindung“ anstelle einer erfundenen Null – und niemals ein Wert erraten, den die schreibgeschützte RPC-Verbindung nicht bestätigen kann.
Der Link zum Token-Portal wird nun aus der Konfiguration anstatt von einer fest codierten lokalen Adresse abgeleitet.
Die Formulierung in der Token-Übersicht unterscheidet nun einheitlich zwischen einer genehmigten, aber noch nicht umgesetzten Entscheidung und einer tatsächlich implementierten Version. Dadurch werden mehrere Stellen ersetzt, die sich noch wie ein offener Designvorschlag lasen.
Sicherheit
Es wurde durch einen automatisierten Test bestätigt, dass die Solana-RPC-Verbindungsdetails und die Anmeldeinformationen des Anbieters niemals im Browser-Bundle des Admin Centers, in dessen API-Antworten oder in dessen Protokollen erscheinen.
Eine benutzerfreundlichere Verbindungsfehlermeldung bei Identify
Falls die Pflanzenidentifizierung die Server von CoinGarden nicht erreichen kann, wird Ihnen nun eine Meldung in einfacher Sprache mit einer Schaltfläche „Erneut versuchen“ angezeigt – niemals ein Rohfehlercode – und die App blockiert niemals das Fotoformular, während sie im Hintergrund leise Ihre tägliche Anzahl kostenloser Fotos überprüft.
Verbessert
Ein Verbindungsfehler zu den CoinGarden-Servern wird nun mit einem kurzen Referenzcode protokolliert, den Sie dem Support mitteilen können, und erscheint in der Fehlerüberwachung des Betriebsteams – zuvor war er außerhalb dieses Fehlers nicht sichtbar.
Behoben
Die Seite „Identifizieren“ konnte einen internen Fehlercode („upstream_unavailable“) anzeigen, falls die Fotoidentifizierung kurzzeitig nicht die Server von CoinGarden erreichen konnte. Dieser wurde durch einen leicht verständlichen Text und eine Schaltfläche „Erneut versuchen“ ersetzt, mit der dasselbe Foto erneut gesendet werden kann.
Diese Hintergrundverbindung wird nun automatisch einmal wiederholt, bevor sie abgebrochen wird, für die schreibgeschützten Prüfungen (wie z. B. Ihre tägliche Anzahl kostenloser Daten), bei denen ein Wiederholungsversuch keine doppelten Aktionen verursachen kann.
Die obere und untere Navigation der mobilen App verändert sich nun beim Scrollen – eine kompakte, schwebende Leiste am oberen Seitenrand, die sich beim Weiterlesen sanft zu einer vollständigen, fixierten Leiste ausdehnt und sich wieder zusammenzieht, sobald man zum Seitenanfang zurückkehrt.
Verbessert
Mobile-App: Die Kopfzeile und die untere Navigation wechseln nun animiert zwischen einer kompakten, schwebenden Karte (oben auf der Seite) und einer breiten, am Seitenrand befestigten Leiste (nach dem Scrollen), anstatt überall schwebend zu bleiben – dies entspricht dem ursprünglichen Navigationsgefühl der App.
Der Übergang wird nur bei einem tatsächlichen, bewussten Scrollvorgang ausgelöst – eine kleine Pufferzone um den Schaltpunkt verhindert ein Flackern zwischen den beiden Zuständen.
Jedes animierte Element berücksichtigt weiterhin die Systemanforderung für reduzierte Bewegung und wechselt Zustände sofort anstatt zu animieren.
Eine neue Seite für Erfolge würdigt echte Aktivitäten – Mitgliedschaftsmeilensteine, Pflanzenspenden, Pflegeserien, Bestimmungsnachweise und die Teilnahme an der Community – und zeigt den Fortschritt hin zu den nächsten Zielen klar an. Präsentiere einige Abzeichen in deinem Profil und sieh dir eines neben dem Namen eines Erstellers bei seinen geteilten Blumen an.
Neu
Seite „Erfolge“ (/badges): Alle deine bereits verdienten und noch verfügbaren Abzeichen, gruppiert nach Mitgliedschaft, Pflanzenbeiträgen, Pflanzenpflege, Bestimmung, Community und Besonderem. Jedes Abzeichen zeigt deinen tatsächlichen Fortschritt zum nächsten Meilenstein – niemals eine fiktive Prozentzahl.
Mitgliedschaftsabzeichen werden automatisch nach Kontoalter vergeben, vom Beitritt bis zu sechs Jahren und mehr.
Die Abzeichen für Pflanzenbeiträge werden bei tatsächlichen Meilensteinen der Rettung (1 bis 2,000 gerettete Blumen) vergeben, nicht bei reinen KI-Identifizierungsversuchen.
Pflanzenpflege-Abzeichen belohnen protokollierte Pflegeereignisse und echte 30- und 100-tägige Pflegeserien.
Identifikationsabzeichen belohnen bestätigte Identifizierungen, nicht jeden KI-Anruf
Community-Abzeichen belohnen deine erste geteilte Blume und die echte Wertschätzung, die du von anderen erhältst.
Besondere Abzeichen (Systemwächter, Harmoniebewahrer, Gemeinschaftsleuchtfeuer, Blütenförderer, Kurator seltener Pflanzen) werden von CoinGarden manuell verliehen und können nicht automatisch verdient werden.
Auf der Detailseite des Abzeichens wird genau erklärt, was erforderlich ist und wie nah Sie dem Ziel sind.
Präsentiere bis zu fünf deiner verdienten Abzeichen in deinem Profil – du entscheidest, welche sichtbar sind, und nicht präsentierte Abzeichen bleiben privat.
Ein hervorgehobenes Abzeichen erscheint nun neben dem Namen des Erstellers auf dessen öffentlichen Blumenbeiträgen.
Eine optimierte, bewegungsarme Benachrichtigung „Erfolg freigeschaltet“ erscheint einmal pro Abzeichen, egal ob du es selbst verdient hast oder jemand anderes es für dich erspielt hat.
Das Admin Center hat die Funktion „Ökosystem → Abzeichen“ erhalten: Alle Abzeichen und deren Anzahl können angezeigt werden, Abzeichen können aktiviert oder deaktiviert werden, spezielle Abzeichen können mit Angabe eines Grundes zugewiesen oder entzogen werden, und es kann eine einmalige Abgleichung durchgeführt werden, bei der jedem bestehenden Konto alle Abzeichen zugewiesen werden, für die es bereits qualifiziert ist – nicht nur das neueste.
Sicherheit
Nur ein Administrator kann ein spezielles Abzeichen zuweisen oder entziehen, und jede Zuweisung, jeder Entzug, jede Aktivierung/Deaktivierung und jeder Abgleich wird mit Begründung im Überwachungsprotokoll protokolliert.
Automatische Abzeichen können nicht von Administratoren manuell angepasst werden, wodurch die eigentliche Bewertung umgangen wird – ein Administrator kann das Abzeichen lediglich aktivieren/deaktivieren, aber niemals ein automatisch erworbenes Abzeichen manuell vergeben oder widerrufen.
Entwickler
Der Badge-Katalog ist vollständig datengesteuert (Metriken + Schwellenwerte werden aus der Datenbank gelesen), daher ist für ein neues Badge niemals eine Codeänderung erforderlich.
Der Fortschritt der Abzeichen wird stets live aus denselben Quelltabellen berechnet, denen auch der Rest des Produkts vertraut (Blumen, Pflegeereignisse, Identifikationen, Blumenbeiträge, Blumenbeitrags-Likes) – es gibt keine separate Fortschrittstabelle, die mit der Synchronisierung in Konflikt geraten könnte.
Entsperrbenachrichtigungen werden durch Abfrage eines nicht sichtbaren/bestätigten Flags anstatt über einen Push-Kanal zugestellt, sodass ein durch Ihre eigene Aktion, die Aktion einer anderen Person (ein Like) oder einen Administratorabgleich verdientes Abzeichen alle auf die gleiche Weise angezeigt werden.
Das Problem, dass die Vorschaubildanzeige der mobilen App für Crawler blockiert wurde, wurde behoben.
Das neue Vorschaubild der Teilen-Funktion der mobilen App (Version 0.7.5) war für Facebook, X und andere Link-Crawler nicht erreichbar – sie wurden auf die Anmeldeseite weitergeleitet, anstatt das Bild zu sehen, da sich diese Crawler nie anmelden. Behoben.
Behoben
Mobile App: Die Routen `opengraph-image` und `twitter-image` befanden sich nicht auf der Liste der zulässigen öffentlichen Routen. Daher leitete die standardmäßige Anmeldepflicht für persönliche Seiten jede Crawler-Anfrage auf die Anmeldeseite um, anstatt das Bild auszuliefern. Dies wurde live bestätigt (HTTP 307) und behoben, indem beide Routen derselben Liste zulässiger Routen hinzugefügt wurden, die bereits `robots.txt` und `sitemap.xml` umfasst.
Ein Bereitstellungsfehler in der Share-Image-Version 0.7.4 wurde behoben.
Die Vorschaubilder der vorherigen Version ließen sich lokal erstellen und ausführen, konnten aber aufgrund einer Cloudflare-spezifischen Inkompatibilität nicht auf der Website, der mobilen App und dem Token-Portal bereitgestellt werden. Das Problem wurde behoben, und die Bilder sind jetzt verfügbar.
Behoben
Die Website, die mobile App und das Token-Portal konnten nach der Veröffentlichung von Version 0.7.4 nicht bereitgestellt werden – die Vorschaubilder enthielten eine Laufzeiteinstellung, die der Cloudflare-Build-Schritt sofort ablehnte. Die Einstellung wurde entfernt (jede App läuft ohnehin in dieser Laufzeitumgebung, unabhängig von der Einstellung) und die Bereitstellung wurde diesmal mit dem tatsächlichen Build und nicht nur mit dem lokalen Build bestätigt.
Echtzeit-Vorschau für die Website, die mobile App und das Token-Portal
Beim Teilen eines CoinGarden-Links auf Facebook, X oder anderen Plattformen wurde zuvor kein Bild angezeigt, und Facebook meldete einen Hinweis auf ein fehlendes og:image. Jetzt generiert jede öffentliche App ein individuelles Vorschaubild, und die mobile App hat den zuvor fehlenden Titel/die Beschreibung erhalten.
Neu
Gebrandete Open Graph- und Twitter/X-Vorschaubilder für die Marketing-Website, die mobile App und das Token-Portal – jeweils in den Farben der jeweiligen App, dynamisch generiert statt als statische Datei zur Synchronisierung.
Behoben
Die mobile App enthielt keinerlei Metadaten für die Social-Media-Vorschau (weder og:title, og:description noch og:image) – ein geteilter Discover- oder Flower-Post-Link zeigte eine einfache, generische Vorschau. Jetzt enthält sie den Namen der App, die Beschreibung und das neue Vorschaubild.
Der Twitter-Card-Typ der Marketingseite war auf ein kleines „Zusammenfassungs“-Layout eingestellt, das kein großes Bild anzeigte, selbst wenn eines vorhanden war – korrigiert zu „Zusammenfassung_großes_Bild“, da nun ein echtes Bild existiert.
Der Discover-Feed für angemeldete Benutzer wurde korrigiert.
Angemeldete Nutzer sahen bei jedem Besuch von „Entdecken“ die Meldung „Community-Blumen konnten nicht geladen werden“ – ein Fehler in der Verbindung zwischen der App und der Funktion für personalisierte Empfehlungen, kein tatsächlicher Ausfall. Das Problem wurde behoben, sodass angemeldete Nutzer nun ihre eigenen Empfehlungen oder, falls noch keine vorhanden sind, die beliebten Blumen der Community sehen.
Behoben
Entdecken-Feed: Angemeldete Nutzer sehen nicht mehr die Fehlermeldung „Konnte nicht geladen werden“ – der personalisierte Feed wird jetzt korrekt geladen und zeigt die beliebtesten Blumen der Community an, falls noch keine personalisierte Auswahl vorhanden ist.
Der Absturz beim Bearbeiten durch den Benutzer wurde diesmal endgültig behoben.
Die vorherige Lösung für den Absturz der Benutzerbearbeitungsseite funktionierte nicht – das Speichern führte weiterhin zum Absturz. Diese Lösung hingegen schon: Die Weiterleitung nach dem Speichern entspricht nun exakt dem Muster, das sich im gesamten Admin Center bereits bewährt hat.
Behoben
Admin Center: Das Ändern der Rolle, des Status oder des Anzeigenamens eines Benutzers führt nach dem Speichern nicht mehr zum Absturz der Seite – dies wurde durch einen erneuten Test der fehlerhaften Aktion im Live-Betrieb bestätigt, nicht nur durch einen sauberen Build.
Es wurde ein Absturz beim Speichern von Benutzeränderungen im Admin Center behoben.
Das Speichern einer Rollen-, Status- oder Namensänderung auf der Benutzerkontoseite konnte zum Absturz der Seite führen, anstatt das Ergebnis anzuzeigen. Das Speichern selbst war nie das Problem – die Seite wurde anschließend einfach nicht korrekt neu geladen. Behoben.
Behoben
Admin Center: Das Ändern der Rolle, des Status oder des Anzeigenamens eines Benutzers führt nach dem Speichern nicht mehr zum Absturz der Seite – die Bestätigung wird nun korrekt angezeigt.
Administratorbenutzerverwaltung und zwei echte Fehler behoben
Administratoren können nun Anzeigenamen bearbeiten, Rollen ändern und Konten direkt im Admin Center aktivieren oder deaktivieren. Jede Änderung wird im Überwachungsprotokoll protokolliert. Das Überwachungsprotokoll selbst wurde korrigiert – es wurde zuvor nicht geladen – und die Warnung auf der Statusseite bezüglich Versionskonflikten wurde behoben, um Fehlalarme während der Bereitstellung zu vermeiden.
Neu
Admin-Center: Die Benutzerkontoseite ermöglicht nun das Bearbeiten des öffentlichen Anzeigenamens, das Ändern der Rolle (Benutzer/Moderator/Administrator) sowie das Aktivieren oder Deaktivieren des Kontos – serverseitig durchgesetzt, mit dem gewohnten Schutz durch den letzten Administrator und der Bestätigung der Selbstdeaktivierung.
Die Statusseite zeigt nun eine Tabelle mit Dienst / Erwarteter Version / Bereitgestellter Version / Commit / Status an, sodass eine tatsächliche Bereitstellungslücke auf einen Blick erkennbar ist, anstatt in einer Versionsliste versteckt zu sein.
Behoben
Die Seite mit dem Audit-Protokoll im Admin Center schlug immer mit der Fehlermeldung „Antwort, die diese Konsole nicht erkannt hat“ fehl – die API-Route lieferte nie die benötigte Seitenstruktur. Jetzt funktioniert es, und die Seite lädt korrekte Einträge.
Die Warnung „Versionskonflikt“ auf der Seite „Status“ wurde ständig und fälschlicherweise ausgelöst, da die API-eigene Selbstprüfung eine Versionsnummer meldete, die bei den Releases nie aktualisiert wurde. Jetzt liest sie bei jeder zweiten Prüfung dieselbe gemeinsame Version, und die Warnung wird erst ausgelöst, wenn ein Versionskonflikt tatsächlich länger als eine normale Bereitstellung besteht, nicht mehr während einer laufenden Bereitstellung.
Ein fehlerhafter, nicht erreichbarer Status-Endpunkt der API beschrieb noch die Blockchain vor der Migration; wurde im Rahmen der Versionskorrektur in derselben Datei behoben.
Sicherheit
Jede Änderung der Benutzerverwaltung (Anzeigename, Rolle, Status) wird mit Ergebnis und Korrelations-ID im Audit-Log protokolliert, sodass sie bis zur genauen Anfrage zurückverfolgt werden kann, die sie ausgelöst hat.
Entwickler
Das Audit-Log erhielt eine echte serverseitige Paginierung und Ergebnisverfolgung (`result`, `correlation_id`) anstelle einer unbegrenzten, nicht paginierten Liste.
Die Integritätsprüfungen protokollieren nun einen Build-Commit, wenn die Integritätsnutzlast eines Dienstes einen solchen meldet, und schaffen damit die Grundlage für die neue Versionstabelle.
Ein intelligenterer Discover-Feed und weniger Sackgassen
Der Entdecken-Feed präsentiert nun täglich eine KI-gestützte Empfehlung neben den beliebtesten Blumen, inklusive einer kurzen Beschreibung auf jeder Karte. Die Pflanzenidentifizierung ist insgesamt übersichtlicher, und einige kleinere, aber dennoch relevante Fehler – wie ein abgeschnittener „Erinnern“-Button und ein verwirrender Feed-Fehler – wurden behoben.
Neu
Auf der Startseite des „Entdecken“-Feeds wird täglich eine „Gartenempfehlung des Tages“ angezeigt, die einmal täglich von CoinGarden AI aus den beliebtesten Blumen der Community zusammengestellt wird – mit einer einfachen, ehrlichen Alternative zur Standardreihenfolge, falls die KI-gestützte Auswahl nicht verfügbar ist.
Jede geteilte Blumenkarte enthält nun eine kurze Beschreibung aus dem Pflanzenkatalog.
Die Pflanzenidentifizierung bietet nun separate Aktionen wie „Foto aufnehmen“ und „Aus Galerie auswählen“ anstelle einer einzigen, mehrdeutigen Schaltfläche.
Eine Pflanze, die CoinGarden noch nicht erkennt, führt nicht mehr zu einer Sackgasse – durch Antippen wird nun der Katalog nach einer passenden Pflanze durchsucht oder die manuelle Suche mit bereits vorgeschlagenen Pflanzenarten gestartet.
Verbessert
Die Ergebnisse der Identifizierung zeigen einen deutlicheren ausgewählten Zustand – die gesamte Karte ist antippbar und mit einem Häkchen versehen.
Hochgeladene Fotos werden nun als echte Bilddateien verifiziert, anstatt nur anhand der Dateiendung als solche erkannt zu werden; ein nicht unterstütztes Format wie HEIC gibt dies nun deutlich an, anstatt stillschweigend einen Fehler zu melden.
Behoben
Die Schaltfläche „Erinnere mich“ bei den Pflegehinweisen für Blumen wird auf schmalen Handybildschirmen nicht mehr zu einem unleserlichen Streifen gequetscht.
Der Discover-Feed zeigt nicht mehr gleichzeitig „konnte nicht geladen werden“ und „noch niemand hat gepostet“ an – eine fehlgeschlagene Verbindung und eine leere Community sind unterschiedliche Situationen, und der Feed zeigt jetzt an, welche tatsächlich vorliegt, mit einer funktionierenden Option „Erneut versuchen“.
Entwickler
Die Metadaten für Suchmaschinen wurden in allen CoinGarden-Anwendungen korrigiert – kanonische Links, Sitemaps und robots.txt verweisen nun auf die tatsächlichen CoinGarden-Adressen und nicht mehr auf bereits aktive, nicht damit zusammenhängende Domains.
Es wurde bestätigt, dass die privaten Seiten des Admin-Centers in der Produktionsumgebung vollständig von der Suchindexierung ausgeschlossen wurden.
Die Suche nach Pflanzen anhand ihres Trivialnamens funktioniert jetzt so, wie sie soll – auch nach „Rose“. Der Katalog wuchs von etwa zwanzig Zimmerpflanzen auf Hunderte von echten Arten, Gattungen und Familien an, wobei alte wissenschaftliche Namen und Trivialnamenvarianten alle zum richtigen Ergebnis führen.
Neu
Der Pflanzenkatalog wuchs von etwa 20 handverlesenen Zimmerpflanzen zu einer umfassenden Taxonomie von rund 440 Arten, Gattungen und Familien an, die Zimmerpflanzen, Gartenblumen, Rosen, Orchideen, Sukkulenten und Kakteen, gängige Bäume und Sträucher, Kräuter, Gemüse und Obst umfasst.
Die Suche nach einem alten oder alternativen wissenschaftlichen Namen findet nun die richtige, aktuell anerkannte Art.
Die Suche nach einem Gattungsnamen (z. B. „Rosa“, „Hibiscus“, „Monstera“) zeigt alle Arten an, die CoinGarden in dieser Gattung kennt.
Tippfehlertolerante Suche nach gebräuchlichen Pflanzennamen
Das Admin-Center hat eine Pflanzenkatalogseite erhalten: Dort finden sich Statistiken zur Abdeckung, die Herkunft der Daten jedes Eintrags und Informationen zu erfolglosen Suchanfragen – so werden Lücken im Katalog sichtbar statt unsichtbar.
Verbessert
Die KI-gestützte Pflanzenbestimmung ist ehrlicher, wenn sie sich nur bei der Gattung sicher ist, nicht aber bei der genauen Art – sie gibt dies nun an, anstatt eine bestimmte Art zu erraten.
Der Bildschirm „Pflanzenkatalog durchsuchen“ erklärt, was Sie vor Beginn eingeben müssen, und schlägt vor, einen allgemeineren Begriff zu verwenden, anstatt einfach nur anzuzeigen, dass keine Treffer gefunden wurden.
Behoben
Die Suche nach „Rose“ (und vielen anderen gebräuchlichen Namen) im Pflanzenkatalog liefert nun nicht mehr die Meldung „Keine passende Art gefunden“ – dem Katalog fehlten in der Produktionsumgebung die Daten, nicht nur die Suchlogik.
CoinGarden öffnet seine Pforten: Durchstöbern Sie die Blumen der Community und identifizieren Sie bis zu fünf Pflanzen pro Tag ohne Konto, teilen Sie Ihre eigenen Blumen, wann immer Sie möchten, und erhalten Sie einen KI-personalisierten Entdeckungsfeed, wenn Sie angemeldet sind.
Neu
Ein öffentlicher Feed mit Blumenentdeckungen im Dashboard – die beliebtesten geteilten Blumen der Community, kein Konto erforderlich
Als Gast können Sie täglich bis zu fünf Pflanzen auswählen; Ihr kostenloses Limit wird jeden Tag automatisch zurückgesetzt.
Teilen Sie eine Blume mit der Community, wann immer Sie möchten – eine klare Bestätigung zeigt genau an, was öffentlich wird, und Sie können die Veröffentlichung jederzeit rückgängig machen.
Gefällt Ihnen Ihr Lieblingsblumenmuster (Anmeldung erforderlich) und entdecken Sie, was die Community liebt.
Angemeldete Nutzer erhalten einen personalisierten Feed mit kurzen KI-Gartennotizen, die auf dem Pflanzenkatalog basieren.
Ein öffentlicher Anzeigename zum Teilen – bis Sie einen auswählen, werden Sie als „CoinGardener“ angezeigt, niemals als Ihr Google-Name oder Ihre E-Mail-Adresse.
Meine Gärten: Ihre persönliche Pflanzenpflege-Plattform – Blumen, Gärten, Pflegehinweise und Erinnerungen – wurde vom Dashboard mit einer neuen Übersicht verschoben.
Verbessert
Die untere Navigation passt sich nun Ihren Bedürfnissen an: Entdecken, Bestimmen, Meine Gärten und Profil nach dem Einloggen; Entdecken, Bestimmen, Startseite und Anmelden als Gast
Auf der Anmeldeseite wird erklärt, welche Vorteile ein Konto bietet – das Surfen und die tägliche Identifizierung bleiben auch ohne Konto kostenlos.
Sicherheit
Ihre privaten Blumen, Gärten, Notizen, Pflegehistorie und Erinnerungen werden niemals öffentlich angezeigt – es werden nur die von Ihnen freigegebenen Felder als Momentaufnahme geteilt.
Die Beschränkung der Gastidentifizierung wird serverseitig anhand einer anonymen, gehashten Besucher-ID durchgesetzt – niemals anhand einer IP-Adresse oder E-Mail-Adresse.
Die Anzahl der Likes wird serverseitig berechnet, wobei in der Datenbank garantiert wird, dass jede Person mindestens ein Like erhält.
Alle zwölf CoinGarden-KI-Agenten verfügen nun über reale Implementierungen, wählen ihr eigenes Modell anhand von Kosten und Leistungsfähigkeit und arbeiten nach einem Zeitplan.
Neu
Alle zwölf KI-Agenten sind implementiert und im Einsatz: Chat, CGW-Überwachung, tägliche Systemprüfung, mobile Einblicke, Sicherheits-Triage, Anlagendatenqualität, Produktanalysen, Kostenoptimierung, Freigabequalität und CGW-Dokumentenvalidierung
Die Agenten wählen ihr Modell automatisch selbst – das günstigste, dessen Fähigkeiten überprüft wurden und das den Akzeptanztest des jeweiligen Agenten besteht.
Geplante Agenten werden jetzt tatsächlich ausgeführt: Ein Dispatcher arbeitet im Fünfzehn-Minuten-Takt mit höchstens einmaliger Zustellung.
Eine Warteschlange für Ergebnisse, die die Aufmerksamkeit einer Person erfordern
Ein täglicher KI-Digest auf der Startseite des Admin-Centers, basierend auf realen Läufen.
Führen Sie bei Bedarf einen beliebigen Analyseagenten aus; die geschätzten Kosten werden angezeigt, bevor Sie die Schaltfläche drücken.
Verbessert
Jeder Agent berechnet seine Werte in SQL und lässt sie von einem Modell interpretieren, was sowohl kostengünstiger als auch weniger fehleranfällig ist.
Die Berichte werden anhand der vorgelegten Beweise bewertet; eine vom Modell erfundene Zahl wird daher eher markiert als veröffentlicht.
Die Überprüfung der Modellfähigkeit meldet nicht mehr, dass ein reines Textmodell keine strukturierte Ausgabe erzeugen kann.
Die Preisgestaltung der OpenAI-Modelle ist nun bekannt, sodass Kostenvergleiche real und nicht mehr willkürlich sind.
Sicherheit
Der Chatassistent kann ausschließlich die Daten der Person lesen, mit der er spricht; dies wird im Code und nicht durch Anweisungen erzwungen.
Die CGW-Überwachung ist konstruktionsbedingt schreibgeschützt: Es existiert kein Signaturschlüssel und es wird kein Schreibpfad bereitgestellt.
Fügt eine zentrale Verwaltung der KI-Anbieter hinzu, verbessert die Blumenerkennung und führt Versionshinweise in der App mit Update-Benachrichtigungen ein.
Neu
KI-Kontrollzentrum zur Verwaltung von OpenAI- und Anthropic-Verbindungen an einem zentralen Ort
Die Blumenerkennung erfolgt nun über einen konfigurierbaren KI-Agenten, wobei die Herkunft anzeigt, welches Modell welchen Vorschlag erzeugt hat.
Versionshinweise finden Sie unter /changelog in jeder CoinGarden-Anwendung.
In-App-Benachrichtigung bei Bereitstellung einer neueren Version
Installieren Sie CoinGarden über die mobile App auf Ihrem Startbildschirm.
Verbessert
Die Erkennungsergebnisse enthalten nun eine Validierungsbewertung und können von Ihnen jederzeit korrigiert werden.
Administratoren können Modelle hinsichtlich Genauigkeit, Latenz und Kosten vergleichen, bevor sie wechseln.
In der Fußzeile jeder Anwendung wird nun die verwendete Version angezeigt.
Behoben
Die Übersicht des Admin Centers wird nun auch bei kürzlich aufgetretenen Fehlern geladen.
Die Admin-AI-Seiten werden nun auch auf schmalen Bildschirmen korrekt angezeigt.
Sicherheit
Die Schlüssel des KI-Anbieters werden verschlüsselt gespeichert und können niemals aus dem System ausgelesen werden.
Entwickler
Datenbankmigrationen werden nun automatisch bei der Bereitstellung angewendet.
Die kontinuierliche Integration führt die gesamte Testsuite aus.