Skip to content

GAMB2LE modernization programme

This programme makes the GAMB2LE codebases easier to change while preserving their existing behaviour. It is deliberately sequenced: first establish an authoritative, recoverable baseline; then bring sanctioned source revisions onto main; then make small, independently verifiable refactors.

The 8 September reconciliation register records the organisation-wide source assessment, recovery evidence and staged rollout. The historical baselines below remain available for rollback.

Scope

The active implementation scope is:

  • aurora_cloud_dashboard
  • aurora-cloud-infra
  • aurora-edge-infra
  • aurora-dashboard-ios and aurora-dashboard-android
  • aurora-les
  • aurora-les-cases
  • aurora-model-evaluation
  • realtime-scripts
  • iceflux-scripts, iceflux_cloud_dashboard, and iceflux-cloud-infra
  • Cloudnet operations and the existing cloudnetpy fork
  • operations, data-product metadata and documentation repositories that support those systems

chillybat and holoimg are explicitly out of scope. This programme does not change them, their source, their configuration, or their documentation.

greenland-gateway-spine-impact is also out of scope: it is proposal-writing work and must not be folded into this operational modernization programme.

Non-negotiable safety rules

  1. Preserve public routes, CLI options and exit codes, service-unit names, MQTT/file contracts, and scientific artifact schemas unless a separately approved migration changes one.
  2. Before changing a repository, create or verify a pushed, annotated rollback tag. Never force-move or reuse a rollback-* tag.
  3. A source rollback tag is not a configuration backup. Before any deployment, capture a non-secret configuration snapshot and a deployment manifest on the target host.
  4. Validate in development first. Promote the exact tested commit or tag to production; do not rebuild or deploy a different revision.
  5. Use git revert for a published rollback. Do not rewrite main or pull over a dirty operational checkout.
  6. Keep a deployment ledger with repository, commit, tag, artifact/configuration fingerprint, validation result, and rollback target. The ledger must not contain credentials, private keys, or secret values.

Delivery order

  1. Recover deployment provenance and preserve any source or configuration that has not yet been reconciled with its canonical repository.
  2. Converge approved pushed/deployed revisions onto main, one repository at a time.
  3. Add contracts, golden fixtures, reproducible test environments, CI, and deployment markers.
  4. Delete only proven dead code, then extract exact duplicate helpers.
  5. Split oversized modules behind stable compatibility façades.
  6. Schedule dependency, framework, schema, systemd, and cross-repository architecture changes as dedicated migrations.

See the current rollback baseline register before starting a repository pass.

Review gate for every pass

Every pull request must name:

  • the current behaviour that remains stable;
  • the structural improvement being made;
  • the parity check and its result;
  • the exact rollback tag or prior release to restore; and
  • any migration deliberately excluded from the change.