conductor/SLICE11.md

SLICE11 — Independent Conductor release and installed application packages

Status: In progress

Purpose

Release an independently installable Conductor with the completed management and identity features, and finish separation of installed-app code from the core container image.

Working instructions

Read CODEX.md and applicable AGENTS.md instructions before work. Current source and tests are authoritative. Preserve unrelated working-tree changes. Use this file as both the slice specification and its continuing log.

The user authorized SLICE11 on 2026-09-13. SLICE12 and SLICE13 remain separate. Update the checklist and append dated log entries as work proceeds. Record decisions, changed files, checks and results, failures, unresolved issues and the next action. Do not erase earlier log entries or claim VM/release acceptance from local tests alone.

Scope

• Define a versioned installed-application package containing frontend assets and the metadata needed for discovery and controlled API access.
• Keep installed application files in persistent storage separate from the core Conductor image.
• Provide a generic host/integration mechanism that preserves Conductor authentication and backend authorization; do not allow arbitrary user-supplied backend code.
• Adapt Social Scheduler to install/register its own application package without editing Conductor source or rebuilding a special Conductor image.
• Maintain the customer-domain behavior and existing /social-scheduler links where practical.
• Prove the interface with a small second test application; do not implement the future customer control panel yet.
• Verify a fresh core installation has an empty Included with Skeleton Works list and no Social Scheduler dependency.
• Build a versioned release, publish source/artifacts/container image using the existing release conventions, record digests and verify the published artifacts.
• Document compatibility and migration from the current combined Conductor/Social Scheduler image.

Acceptance checks

Action	Purpose / expected behavior
Start standalone Conductor without Social Scheduler	Core management, titles and favicon function independently; the included-app list is empty.
Install Social Scheduler and a second test app	Both apps register and run without patching core source or rebuilding its image.
Restart/recreate the core container	Application packages and metadata persist.
Exercise admin, ordinary-user and anonymous requests	Authentication and API permissions remain enforced for each app.
Fetch the published release and inspect its version/digest	Release artifacts match the tested source and contain SLICE10 changes.

Boundaries and dependencies

Depends on SLICE10. Preserve the earlier completed slices and their logs.

The customer control panel and other SaaS backlog items remain outside these four slices. The user reports only one live Conductor instance, which has Social Scheduler installed. A clean Conductor reset is an available fallback if a safe retrofit is impractical; first record the exact scope and backup/recovery plan. This does not authorize wiping the entire VM or deleting Node-RED's saved connections or PostgreSQL's schedules.

Progress log

2026-09-13 — Plan recorded

• Renamed the proposed four phases to SLICE10, SLICE11, SLICE12 and SLICE13, respectively.
• Implementation has not started.

Current handoff

Implementation and local validation are complete. Preparing the exact source commit and published artifacts; customer-VM migration remains SLICE13.

2026-09-13 — Implementation started

• Preserved a pre-slice backup under /home/vwiebe/projects/.local/conductor-slice11-start.
• Chosen host API v1: verified browser asset packages, persistent under Conductor data, with a declarative allowlisted API bridge. No installed backend JavaScript is executed by Conductor.
• Preserve /social-scheduler and /api/social-scheduler. Connection secrets stay server-side; social credentials remain in Node-RED.
• Release target: Conductor v1.1.0 and Social Scheduler 0.5.0. A fresh core has no seeded apps.
• Existing setup/upgrader scripts are not changed in this slice. The new scheduler installer will require the compatible core before it changes customer state.

2026-09-13 — Implementation and local acceptance

• Implemented manifest version 1 / host API 1, persistent verified browser packages, atomic active-version selection, encrypted fixed backend connections, controlled API routes and signed-in runtime context.
• Added the generic package CLI, application loader, and package-aware backup v2; restore still accepts backup v1. A second independent example proves the interface without Social Scheduler-specific core code.
• Social Scheduler 0.5.0 builds its own browser package. Its installer checks host compatibility first, installs through the CLI and preserves the Conductor image and Compose definition.
• Runtime dependencies were updated compatibly, including Express's qs override. Backend production audit: zero vulnerabilities. Existing CRA development/build advisories remain a documented separate toolchain follow-up.
• Source checks passed: 29 backend tests; 29 frontend suites / 531 tests; frontend TypeScript and production build; schema matrix 15 valid / 2 expected-invalid / 2 diagnostic-invalid; documentation links and governance.
• Social Scheduler checks passed: typecheck, 37 core tests, 15 installer tests and real Node-RED/PostgreSQL integration. An initial direct integration invocation lacked its disposable database; rerunning through the supported wrapper passed.
• Browser acceptance passed: 26 identity checks, management workflows, actual independently packaged Social Scheduler, second app, admin/user/anonymous rules, CSRF, bearer delegation, fixed identity/workspace values, query filtering, bounded responses, callback privacy, encrypted connections, update/restart/removal and invalid package rejection.
• Visually inspected Publishing with two installed apps and the independently mounted Social Scheduler compose screen. Layout and icons are correct; screenshots are under test-results/slice11.
• Docker was initially unavailable; the user restarted it. Production checks then found that docker cp cannot target /tmp in the read-only container. Changed installer transfer to private stdin-fed files created by the running non-root process, and the lifecycle fixture to stream tar into its writable temporary area.
• Real hardened-container checks now pass: package installation twice leaves the image unchanged; recreation retains the app; backup/restore recovers the database and deliberately removed package assets.
• No customer VM, social credential, scheduler queue, setup-conductor.sh or upgrade script was changed.