vwiebe/conductor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
conductor/SLICE11.md

9.1 KiB
Raw Blame History

SLICE11 — Independent Conductor release and installed application packages

Status: Complete — v1.1.0 published and publicly verified

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

SLICE11 is complete. Proceed with SLICE12 only when the user requests it, then SLICE13 for the existing VM. The current VM continues running its existing combined installation.

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.

2026-09-13 — Publication and final verification complete

  • Published Conductor v1.1.0, including the exact source archive, compatible Social Scheduler 0.5.0 portable kit, SHA256SUMS and SLICE11-VERIFICATION.json.
  • Release source commit: fc73f26726. Annotated source tag: v1.1.0. The 283 files in the anonymously downloaded Gitea source archive match this commit byte for byte.
  • Published Linux/AMD64 image: gitea.skeletonworks.online/vwiebe/conductor:v1.1.0; matching immutable source identity: git-fc73f2672602.
  • OCI index digest: sha256:ab5e7dcaed065a304660af31e53ffada290b22dc9176ffeb5817f2e7f07ac313.
  • Linux/AMD64 manifest digest: sha256:87a31b370eab199af96c6592799645c98492314eaabdde8e21f2922a414c8d51.
  • Both image tags point to the same tested artifact. Anonymous pull passed; OCI revision/version and architecture matched the source/tag. The anonymously retrieved image passed the production lifecycle suite, including backup/restore of deliberately removed app assets and container recreation.
  • The actual Social Scheduler installer passed repeated installation and recreation checks against this final image. Shellcheck passed. The final browser suite also rejects an upstream response that reflects the private connection token.
  • All four release attachments were fetched without authentication and matched their SHA256 checksums; the public release page and metadata were read back successfully.
  • Publication used one controlled manual image path. Tag-triggered image builds are disabled; the existing workflow is opt-in. Version/source image tags were checked absent and were never overwritten.
  • Built and committed in an isolated release checkout. After publication, proved the original source files were identical and the index was empty, then advanced its branch/index to the release commit without changing working file bytes. The original source folder is ready for the next slice.
  • Local publication evidence and archives are under release/ (ignored by Git); browser screenshots remain under test-results/slice11. The public release entry is the durable artifact receipt.
  • SLICE12 and SLICE13 remain planned. No customer VM was contacted or upgraded, and no customer credentials, Node-RED flows or PostgreSQL schedules were changed.