[adm 10] Build first-class `/ankh/modules` administration and module-owned admin contribution contract

[artiphishle]

Roadmap: #115

Respect the roadmap first and the AGENTS.md file of every repository touched.

Previous roadmap step

[adm 9] (#124) restores production-faithful Preview over the canonical runtime. This issue rebuilds module lifecycle/configuration as a first-class administration area and establishes the extension contract used by module-specific admin pages.

Repository impact

Likely:

• ankhorage/studio
• ankhorage/orchestrator
• module repositories that adopt/contribute the new contract
• ankhorage/zora only if a genuinely reusable admin-schema rendering capability is missing

Pause at package release boundaries per roadmap rule #6.

Goal

Build /ankh/modules as the canonical module administration area and define how standalone modules contribute their own configuration/admin experience without hardcoding module-specific product logic in Studio.

Do not restore the old PluginsPanel/ModulesPanel architecture.

Target routing

Conceptually:

/ankh/modules
/ankh/modules/{moduleId}

• /ankh/modules lists available/installed modules and lifecycle state;
• /ankh/modules/{moduleId} hosts module-specific configuration/admin contribution when one exists;
• modules that require no configuration need no artificial page content beyond useful status/lifecycle information.

Ownership

Orchestrator
  -> module lifecycle / install / uninstall / plan / ledger semantics

Module repository
  -> module-owned configuration contract
  -> module-owned domain behavior
  -> module admin contribution where possible

Studio
  -> module catalog/administration UX
  -> route host/composition
  -> invokes canonical lifecycle/config interfaces

Studio must not accumulate special-case if moduleId === ... UI for every module.

Required design investigation

Choose a production-ready module admin contribution contract after inspecting current module/orchestrator/package boundaries.

Possible contribution styles may include:

• serializable schema/config rendered with ZORA controls;
• registered package-owned React/admin screen contribution where package/runtime boundaries safely allow it;
• no configuration contribution for enable-only modules.

Do not freeze the implementation to one of these examples without checking bundling, standalone usability, generated-app/runtime constraints and security boundaries.

The resulting contract must allow modules to remain independently usable outside Studio while being easy to integrate into Studio.

Requirements

/ankh/modules

• list available and installed modules;
• show meaningful lifecycle/status/health information;
• install/uninstall through @ankhorage/orchestrator ownership;
• expose configuration/admin entry only when a module contributes one;
• handle loading/error/finalization states cleanly;
• no legacy plugins naming/routes unless current canonical naming explicitly requires it.

Module configuration persistence

• determine canonical source of truth for module config/ledger;
• module config changes must flow through owning orchestrator/module contracts;
• no duplicate Studio-only module configuration state;
• define update/reconfigure capability where current orchestrator lifecycle lacks it, if required.

Module-owned admin contribution

Contract must support modules such as localization and Google Fonts without putting their detailed UI/domain logic in Studio.

Avoid a giant Modules page containing hardcoded Google Fonts/localization forms.

Likely files

Studio, non-exhaustive:

src/studioAdminRouteModel.ts
src/ui/admin/AnkhAdminShell.tsx
src/ui/admin/pages/*
src/core/StudioProvider.ts
src/host/orchestrator/*
src/host/http/*

Orchestrator/module files must be identified from current repos before implementation.

Historical reference: late ModulesPanel and earlier PluginsPanel in ankhorage4; preserve capability, not panel architecture or hardcoded module UI.

Phases

Phase 1 — contribution/lifecycle contract

Design and implement canonical module admin/config/update contribution ownership in orchestrator/module packages.

Phase 2 — /ankh/modules lifecycle UX

Build first-class listing, install/uninstall/status and routing.

Phase 3 — contributed admin host

Render/integrate module-owned configuration contributions at /ankh/modules/{moduleId} with robust unsupported/error states.

Tests

Cover at minimum:

• available/installed module resolution;
• install/uninstall lifecycle calls;
• config contribution present/absent behavior;
• module route resolution;
• update/config persistence through canonical source of truth;
• unknown module state;
• no Studio module-ID special-case requirement in generic routing/model logic.

Acceptance criteria

1. /ankh/modules is the canonical module administration area.
2. Module lifecycle remains owned by Orchestrator.
3. Module-specific admin/config behavior can remain owned by module repositories.
4. /ankh/modules/{moduleId} hosts contributed configuration when present.
5. Enable-only modules work without fake configuration UI.
6. Studio has no growing hardcoded per-module UI switch.
7. A canonical config update/reconfigure path exists if needed.
8. Localization and Google Fonts can adopt the strategy in their own issues/work without Studio-specific domain duplication.
9. No old PluginsPanel/ModulesPanel architecture is restored.
10. Behavior-focused tests and full validation pass.
11. No legacy/compatibility/ankhorage4 dependency is introduced.