Public activity, not marketing noise.

The first rule of a public support campaign is that the official surface has to be coherent before people are routed to a cashier. GLEE keeps the proof, status, terms, updates, and supporter records on gleephoenix.com while Ko-fi handles payment details externally.

The site is a statically-rendered site generated from a YAML config and a set of HTML templates. Feed posts like this one live in a content file separate from the config. Machine-readable campaign state is published at /status.json and mirrored to /round-zero.json as a legacy alias. Both status files must match before deploy.

The self-improve loop is central to GLEE's research architecture. Each round, the system proposes mutations to its own task-to-method decision policy, evaluates them against a grounded benchmark, and keeps only improvements. This is the system rewriting its own decision logic. Convergence at 1.0 means the current benchmark is saturated — the next meaningful step is grounding the benchmark in real routing outcomes, not just internal doctrine mappings.

The loop uses a local hill-climbing proposer against a grounded oracle that scores each policy candidate. Each round proposes mutations to the method assignment for each task class, scores against the oracle, and promotes only if the score improves. After 25 rounds the policy converged: no further mutation improved the score. The next evolution is grounding the oracle in real task outcomes rather than synthetic benchmarks.

Before GLEE can safely change which method handles a given task class, it needs to test alternatives without changing live behavior. The shadow system runs challengers silently, records the comparison, and leaves the main path unchanged. No routing change happens until the comparison data supports it — and only after a second verification gate. This is the safety layer for GLEE's self-improvement arc.

The shadow system compares a challenger method against the current incumbent on the same task input. Results are written as advisory receipts — they inform future routing decisions but do not change live routing. The comparison is one-way: the incumbent result is always returned to the caller. Advisory only until a separate promotion gate is passed.

GLEE's research loop produces findings: beliefs about how the system should behave, supported by evidence. Before any finding can change live behavior, it passes through a promotion review. This promotion is the first step: the findings are now written into GLEE's operating memory as advisory beliefs. The next step — if the evidence continues to hold — is an enforcement test before they become hard rules.

Advisory doctrine means: findings may inform foreman decisions and context packets, but may not gate dispatch, mutate memory, or enforce routing. Each finding has an explicit revoke condition. The advisory layer is the standard intermediate step between raw evidence and hard system rules.