Boundless Vector Arena Maintenance Contract

Boundless Vector Arena is feature-frozen as a maintained first-party reference product and technology demonstrator. The closure decision owns that status. This contract defines the default work and proof boundary after closure.

Supported Maintenance

Routine Arena maintenance may include:

• critical correctness, reliability, security, and data-integrity fixes;
• migrations required by intentional engine, framework, API, compiler, or platform changes;
• security and dependency updates that affect the product closure;
• focused test, startup, build, and asset-closure proof needed to preserve the maintained reference surface; and
• documentation corrections that keep implemented capability and limitations truthful.

Excluded By Default

The maintenance track does not include:

• new campaign positions, bosses, enemies, perks, weapons, or other product content;
• procurement, composition, or shipping of production music;
• new UI motion, settings, controller, or accessibility feature expansion;
• store, installer, release, or public-demo packaging;
• final balance passes, long soak, release-matrix completion, or final A/B acceptance; or
• back-porting features from a future Godot or other commercial product.

These items are deferred rather than complete. Starting one requires explicit reactivation under the closure decision.

Validation Policy

Validation is proportional to the affected boundary:

• Documentation-only changes run affected documentation contracts, docs_build, and repository policy/audit checks required by the change.
• Arena-local maintenance runs the closest focused product tests plus the shortest relevant product startup, build, and asset-closure smoke.
• Engine or framework changes that intersect Arena dependencies run the affected engine/framework tests and the smallest Arena integration/startup proof that exercises the changed seam.
• Complete Arena suites and native acceptance are reserved for scheduled regression gates, release-affecting changes, systemic/high-risk migrations, or an explicitly reactivated product milestone.

Arena must remain useful integration evidence without dominating unrelated PixelBullet work. A passing narrow proof does not waive broader validation when the changed dependency or failure mode is systemic.

Reactivation

A reactivation record must name the product owner, bounded objective, consumer, distribution intent, acceptance evidence, maintenance duration, and exit condition. Until that record is accepted, the current implementation and runtime closure are maintained but not expanded.