ChatGrowing

CHANGELOG

What’s new in ChatGrowing.

New features, improvements, and fixes—listed by release.

14DOCUMENTED RELEASES
0.3.0LATEST CANDIDATE
0.1.0CORE FOUNDATION

ChatGrowing 0.3.0

A new identity and a simpler path from an advertising question to a governed answer inside Codex.

  • Introduced the ChatGrowing name, visual identity, Plugin namespace, OAuth resource, and customer-facing product language.
  • Separated everyday queries from long-lived Artifacts. Users can ask ordinary questions and continue drilling down without first publishing an Evidence Artifact.
  • Kept explicit Tool dependencies and added a discoverable Resource Bridge recovery contract for compatible Codex sessions where custom Tools are not exposed.
  • Consolidated the public Remote surface around 13 governed read-only Tools and seven intent-level Remote Skills.
  • Preserved request-scoped organization and resource authorization. The release does not modify campaigns, budgets, bids, status, or creatives.

0.3.0 is currently a release candidate and has not yet been published to the public Marketplace.

0.2.3

A recovery path for Codex sessions where custom Tools are unavailable.

  • Added Resource Bridge access backed by the same read-only authorization and query implementation.
  • Published a fixed recovery contract that compatible Hosts can discover through MCP Resources.
  • Allowed approved read-only queries to run through parameterized Resource Templates without creating a separate query engine.
  • Kept authorization, account scope, input validation, and evidence behavior identical to normal Tool calls.
  • Added protocol observability to distinguish initialization, Tool discovery, Resource discovery, and query execution failures.

The server-side recovery capability was deployed, but the 0.2.3 Plugin was not publicly released.

0.2.2

More reliable Tool discovery in Codex.

  • Declared the remote Ads Read Tool dependency for every published Skill.
  • Improved how Codex connects analysis, monitoring, configuration, and reporting Skills to the remote MCP.
  • Added release checks for the expected server name, Streamable HTTP transport, and Remote MCP URL.
  • Kept all seven published Skills on the same governed Ads Read capability instead of duplicating query logic inside each Skill.

0.2.1

Simpler authentication and evidence-first custom reports.

  • Moved Codex authentication to one allowlisted CIMD OAuth client.
  • Added user-defined reports based on explicitly published evidence.
  • Preserved account scope and metric definitions from query to rendered report.
  • Added report preview, Report Run, rendered asset, and Feishu projection-plan outputs without adding advertising write access.
  • Required every report input to resolve to resources visible to the current signed-in member.

0.2.0

Server-driven reports and shareable report images.

  • Added server-managed report definitions and guidance.
  • Added long-image rendering for governed reports.
  • Kept report availability and formats up to date without changing the thin Plugin.
  • Added binary report-resource reading so rendered images could be retrieved through the governed MCP flow.
  • Established the server-driven bootstrap pattern used to deliver current capability and limitation guidance.

0.1.9

Flexible analysis beyond fixed questions.

  • Added governed follow-up analysis and dynamic continuation.
  • Added cross-source compatibility checks.
  • Improved multi-account exploration while preserving authorization scope.
  • Added capability context and Catalog guidance so queries could be planned from available fields, metrics, grains, and breakdowns.
  • Added constrained SQL and Python analysis over authorized query results for calculations not covered by a fixed summary.

0.1.8

Native Codex authentication without a fixed local callback.

  • Removed the previously fixed OAuth client and callback assumptions.
  • Added Authorization Code with PKCE for public-client authentication.
  • Allowed the Codex Host to register the callback used by each connection.
  • Hardened issuer, audience, resource, and scope validation for the Remote MCP.

This historical dynamic-registration approach was later replaced by the single CIMD client model in 0.2.1.

0.1.7

More dependable sessions across the web product and Codex Plugin.

  • Stabilized OAuth login and session handling for Remote MCP requests.
  • Improved access checks when moving between Dashboard, ad-management, and Plugin workflows.
  • Hardened the public release builder and authentication configuration validation.
  • Reduced false authorization failures caused by session transitions.

0.1.6

Session recovery for interrupted or expired authenticated requests.

  • Added a controlled retry path for requests that encounter an expired API session.
  • Improved authenticated fetch behavior so users could recover without restarting the entire workflow.
  • Pinned the then-current Codex OAuth configuration to reduce client mismatch.

0.1.5

Stricter access control and more dependable advertising semantics.

  • Hardened organization membership, resource binding, and account-scope enforcement.
  • Added stronger checks around app and advertiser selection.
  • Improved semantic profiles for metric definitions and source-specific interpretation.
  • Made unavailable, unauthorized, missing, partial, and genuine-zero results easier to distinguish.
  • Added release gates covering the combined access and semantic surface.

0.1.4

Made the existing 0.1 product available as the first publicly installable thin Plugin.

  • Published the Plugin through a versioned public Git Marketplace.
  • Moved customer installation to a thin package containing stable Skills and Remote MCP configuration.
  • Kept private application code, credentials, tokens, and advertising data out of the public bundle.
  • Added immutable release checks and an explicit rollback version.

0.1.3

The first versioned Codex Plugin candidate for invited teammates.

  • Established the Plugin manifest, versioned Marketplace packaging, and Remote MCP connection.
  • Documented installation, explicit upgrade behavior, and teammate onboarding.
  • Added controlled private distribution before the first public thin-Plugin release.
  • Confirmed that Marketplace updates do not silently replace an already installed Plugin.

0.1.2

Improved the reporting and governed paid-growth workflows introduced in 0.1.0.

  • Strengthened the governed paid-growth analysis flow and corrected early evidence-handling gaps.
  • Improved the Dashboard reporting workflow from source data to a reviewable output.
  • Added basic daily-report automation on top of the existing report foundation.
  • Expanded validation around report composition, delivery state, and operational reliability.

0.1.0

The foundation of ChatGrowing. Most of the product’s core capabilities were established in this first version; later releases focused on making them more flexible, reliable, secure, and easier to distribute.

Advertising data in one governed layer

  • Connected the core data sources. Brought Meta Ads, Google Ads, TikTok Ads, and AppsFlyer into one read-only advertising data layer.
  • Unified delivery and attribution evidence. Used advertising platforms for spend, impressions, clicks, object status, budget, and bidding evidence, while AppsFlyer remained the attribution baseline for conversion outcomes.
  • Preserved source differences. Kept platform-specific hierarchy, metric grain, currency, status, and attribution meaning instead of flattening every source into one ambiguous table.

Core product functions

  • Natural-language advertising questions. Users could ask about spend, conversions, CPI/CPS, pass rate, account performance, campaigns, delivery, and changes over time.
  • Cross-channel summaries and comparisons. The system could compare platforms, accounts, apps, campaigns, and date windows using governed metric definitions.
  • Object-level drill-down. Users could move from a high-level result into provider-native Campaign, AdGroup or Ad Set, Ad, placement, asset, and other available evidence.
  • Performance diagnosis. The analysis flow separated what changed, possible explanations, supporting evidence, counter-evidence, and what still could not be concluded.
  • Configuration inspection. The product could read account hierarchy, delivery status, budget, bid, mapping, and available configuration evidence without changing the advertising platform.
  • Monitoring foundation. Data freshness, account status, delivery risk, balance or policy signals, and report-delivery conditions could be inspected and explained.
  • Report foundation. The same governed data and metric definitions could be composed into repeatable advertising summaries and operational reports.

Evidence and data-quality rules

  • Evidence before interpretation. Answers were grounded in a defined source, resource scope, date range, grain, metric contract, and freshness state.
  • Unknown was not treated as zero. Missing data, unavailable fields, incomplete mapping, insufficient permission, synchronization failure, and a real zero result remained different states.
  • Attribution dates stayed explicit. Actual event dates and D0/D1/D3 cohort views were not silently mixed.
  • Partial evidence stayed partial. The product did not promote incomplete hierarchy, asset, or attribution evidence into a confident conclusion.

Access and safety boundaries

  • Queries were restricted to the organization, resources, apps, and advertising accounts available to the current user.
  • The advertising MCP was read-only and did not modify campaigns, budgets, bids, status, targeting, or creatives.
  • The model did not receive direct database, production-server, credential, or secret access.
  • Recommendations remained reviewable suggestions; no advertising action was applied automatically.