Rebrand Program¶

This page is the published progress tracker for the Arqon Maestro full rebrand.

The detailed migration playbook lives at the repo root in LEGACY_INTERNAL_RENAME_TODO.md.

This page is the simpler operational dashboard for watching progress in the docs site.

Video placeholder: rebrand program overview and progress review.

Program Goal¶

Complete the migration from inherited serenade naming to a coherent Arqon Maestro identity across:

docs
UI
config
repo layout
process names
internal slugs
namespace and dependency identity

Phase Tracker¶

Phase	Name	Risk	Status	Exit Condition
0	Freeze Scope	Low	`planned`	baseline captured and scope discipline active
1	User-Facing Cleanup	Low	`completed`	user-facing docs and runbooks use Arqon Maestro naming as the canonical product identity
2	Arqon-First Compatibility Layer	Medium	`completed`	`.arqon` / `arqon.json` and `ARQON_MAESTRO_*` are primary while legacy fallbacks remain active
3	Repo Subtree Rename	Medium	`completed`	`maestro/` is now the top-level engine subtree and repo-path references have been repaired
4	Sidecar and Runtime Process Identity	High	`completed`	primary sidecar and packaged local processes now use Arqon Maestro names with legacy fallbacks preserved
5	Config Storage and Logs Migration	Medium	`completed`	live Maestro config, scripts, and logs now migrate into `.arqon` while legacy storage remains preserved
6	Safe Internal Slug Rename	Medium	`completed`	internal Python tooling slug moved to `scripts/arqon_maestro` and related low-risk references cleaned up
7	Namespace and Dependency Migration	High	`completed`	deep technical identity migration complete

Current Focus¶

The current focus is:

all seven planned rebrand phases are hard-closed
preserving the compatibility shims that still protect active users
treating external infrastructure and historical/provenance cleanup as post-program follow-on work
follow-on planning now lives in:
External Infrastructure Ownership Plan
Historical And Provenance Audit Plan

Program Records¶

Keep these three records updated together:

Decision Log: architectural and compatibility decisions
Gotcha Registry: repeatable traps and migration hazards
Rebrand Program: current phase status and hard-close expectations
Evidence Packs: command/results evidence for high-risk phases
Follow-On Plans: post-program workstreams that intentionally sit outside the seven rebrand phases

Phase Rules¶

complete one phase at a time
verify before moving on
close each phase with a hard-close pack
do not delete compatibility shims early
treat runtime identity changes separately from visible branding changes

Hard-Close Pack Requirements¶

Every completed phase must record:

scope completed
files changed
breaking changes introduced
compatibility shims added or removed
verification performed
residual risks
rollback point
next phase entry criteria

Use the published template here:

Phase Closeout Template

Status Legend¶

planned: not started
in_progress: active work
blocked: cannot continue safely yet
completed: hard-close pack finished
rolled_back: phase reverted or partially undone

Risk Map¶

flowchart LR
  P1[User-facing cleanup] --> P2[Compatibility layer]
  P2 --> P3[Repo subtree rename]
  P3 --> P4[Sidecar/process rename]
  P4 --> P5[Config migration]
  P5 --> P6[Internal slug rename]
  P6 --> P7[Namespace/dependency migration]

Next Update Rule¶

Whenever a phase changes state:

update this page
update the decision log if a critical decision was made
update the gotcha registry if a new trap was discovered
update the detailed strategy document
create or update the phase closeout record