PR #29 delivers the full AOS CE product implementation, encompassing migration tooling and signed channel support, marking a major milestone for the AOS community edition. PR #4 rebuilds the AOS product site and developer guide from the ground up, ensuring documentation keeps pace with the completed feature set. Together these two PRs from @joshuajbouw bring the AOS CE surface — both the runtime and its public-facing documentation — to a shippable state. Signed channels in particular establish a verified communication layer that downstream integrators can rely on for authenticated message delivery.

PR #18 in sphere-ui introduced the core author-chosen banner framing feature, allowing content creators to define how their banner is cropped and positioned rather than accepting a default. PR #444 in sphere carried that work into the marketplace, ensuring the selected framing is applied consistently across every screen size and device class, eliminating the visual inconsistency that existed before. PRs #24 and #26 wired the new sphere-ui 0.1.32 capability into sphere-backoffice and sphere-dev-portal respectively, giving editors in both portals access to the banner frame editor UI. This chain of PRs from @KruGoL closes the loop from component library through to every consumer surface.

PR #19 corrected where the maxSize constraint is applied in sphere-ui: the limit is now enforced on the baked (processed) output file rather than the raw picked source, which is the semantically correct boundary for storage and delivery quotas. PR #20 followed up by removing the stored-size cap from the picker's advertised constraints so the UI no longer misleads authors into thinking the limit applies at selection time. PRs #25 and #27 bumped sphere-backoffice and sphere-dev-portal to sphere-ui 0.1.34 to pull in both fixes, keeping downstream portals honest about what the picker does and does not restrict. The net effect is accurate user-facing copy and a correctly enforced file-size policy across all upload flows.

PR #442 addresses a double-payment vulnerability tracked in issues #440 and #441, where keep-open send codes could be presented as re-sendable despite a payment already being in flight. The fix forces all keep-open send codes into a persistent pending state, preventing users from triggering a second payment submission on the same code. This is a targeted safety fix by @MastaP with direct user-facing impact, protecting wallet balances from erroneous duplicate charges until a code is explicitly resolved or cancelled.

PR #72 by @lploom introduces automatic API key privilege downgrading for GET requests hitting the aggregator-subscription service. This means that read-only requests are transparently handled with a reduced-privilege key, limiting the blast radius of any credential exposure on non-mutating endpoints. The change improves the security posture of the aggregator subscription layer without requiring callers to manage multiple keys themselves. It is a defensive, infrastructure-level hardening measure that aligns key privilege with actual request intent.