AFTERGROWTH Protocol

Inspiration

AI makes adding a feature easier. Reviewing everything that changed is still a maintainer's job. A matching version number and a passing new-feature check can both hide a regression. AFTERGROWTH gives that review a small, concrete setting: a garden whose existing species must survive the addition of night flowers.

What it does

The demonstration connects three decisions to inspectable evidence. A useful candidate produces five flowers at night and none at noon while preserving moss, reeds and motes. A second candidate has the same generation ID and working flowers, but loses moss; an inherited condition rejects it before introduction. A separate controlled routing fault is injected after preflight. The stable route is restored to the last verified night-flower habitat and checked again. All eight final HTTP checks pass.

The browser makes these recorded observations easy to compare. Reviewers can inspect the timestamp, observed values and event trace, with English and Japanese explanations. The services and traffic router run during the reproducible local rehearsal. Browser clicks explore its saved record; they do not invoke live AI or deploy a production service.

How we built it and used GitLab Duo

GitLab Duo Agent Platform session 9461709 enabled night-flower behavior already present in the renderer by changing world data, added tests, and opened merge request !1. A separate assisted correction fixed three test files before that MR's CI passed. The local HTTP verification and recovery harness was added later; it is not attributed to the original Duo session.

TypeScript, Node.js, Git-versioned world and lineage data, Vitest and Playwright keep the implementation small and reproducible. GitLab CI runs verification, browser tests, policy checks, dependency auditing, secret detection, static analysis, and a container check that links the scanned image to the runtime smoke test. A manually requested pipeline publishes the saved demonstration to the existing GitLab Pages site after those jobs succeed. Each published record identifies its actual source commit and pipeline.

Challenges

The generation identifier alone did not establish correctness: both an unsuitable candidate and a deliberately wrong route could report the expected ID. We separated a trusted acceptance contract from the service response, preserved inherited obligations, and verified the stable HTTP route again after restoration. We also kept the actual Duo contribution separate from subsequent assisted repairs and verification work.

Accomplishments and evidence

• A real Duo session and merge request with traceable contribution and correction history.
• A repeatable local trial covering acceptance, moss-loss rejection, a post-switch routing fault, restoration and a final HTTP check.
• An inspectable record with 24-hour candidate observations and eight final checks.
• An English/Japanese demonstration that explains the maintainer's decision before the garden metaphor.
• A 2:40 English video using actual project screens and historical records.

What we learned

Successful feature generation is only one part of acceptance. Existing behavior, what the route actually serves, and whether restoration succeeded all need their own observations. A small visible model can make these distinctions easier to review without pretending that a simulation is a production deployment.

What's next

Connect the reviewed local contract to an independently enforced release boundary, then demonstrate a real deployment and recovery loop. Unattended production releases, cloud recovery, repeated hands-off Issue-to-production runs, and measured productivity or sustainability gains remain unproved. No Google Cloud or environmental bonus is claimed.

Built With

• docker
• gitlab
• gitlab-ci
• gitlab-duo
• gitlab-pages
• gitleaks
• node.js
• playwright
• semgrep
• svg
• trivy
• typescript
• vitest