fix(apps): declare minEngine=0.6.6 on catalog entries that use commandArgv/stopGracePeriod (#599)

[santhiprakash]

Problem

Five bundled apps (posthog, clickhouse, minio, neon, redis) ship services that use post-release serviceSpec fields (commandArgv, stopGracePeriod). These fields were added to the template schema in commit 550fe22 and first shipped in v0.6.6, but no entry declared minEngine, so the engine-gate in apps/api/src/modules/apps/catalog-source.ts had nothing to compare against and could not refuse a pre-0.6.6 install.

The silently-dropped field produces wrong-role containers:

• PostHog worker installs without a command and silently runs the wrong role (this is the reporter's concrete observation in the issue).
• MinIO exits with 'sh' is not a minio sub-command because the shell-wrapped command never reaches the entrypoint.

Root cause

packages/core/src/apps/schema.ts documents the two fields as post-release additions (the commit message in 550fe22 spells out the same MinIO reproducer), but the schema-level commandArgv/stopGracePeriod are accepted by every entry without a corresponding minEngine claim, so the engine-version check in templateEngineOk(entry.minEngine, engineVersion) always returns true (because minEngine is undefined → always ok).

The reporter's claim that "PostHog worker installs with no command" lines up exactly with this: on a pre-0.6.6 engine, the field is dropped and the container starts with whatever the image default is.

Fix

Add "minEngine": "0.6.6" to each of the five catalog entries that use the post-release fields, so the engine-gate now has a real value to compare against:

• packages/core/src/apps/catalog/posthog.json — worker / web / ingestion-* use commandArgv
• packages/core/src/apps/catalog/clickhouse.json — uses stopGracePeriod
• packages/core/src/apps/catalog/minio.json — uses commandArgv (the MinIO reproducer)
• packages/core/src/apps/catalog/neon.json — uses stopGracePeriod
• packages/core/src/apps/catalog/redis.json — valkey uses commandArgv

packages/core/src/apps/catalog.json is regenerated via bun scripts/gen-catalog.ts to mirror the source-of-truth catalog/*.json files.

Verification

Regression test added in packages/core/src/apps/catalog.test.ts that walks every entry's services and asserts: any service that sets commandArgv or stopGracePeriod must declare entry.minEngine that satisfies templateEngineOk(minEngine, "0.6.6").

Sabotage run: removed minEngine from posthog.json → new test fails with:

posthog/redis7 uses a post-0.6.6 serviceSpec field but entry has no minEngine — engine gate cannot refuse pre-0.6.6 installs

Restoring the field → full suite passes:

27 pass  0 fail  87 expect() calls  (packages/core/src/apps/catalog.test.ts)
809 pass 0 fail  3895 expect() calls (full packages/core bun test)

Targeted apps/api checks (INTERNAL_TOKEN=... DEPLOY_MODE=desktop OPENSHIP_AUTH_MODE=none bun test test/modules/apps/catalog-resolve.test.ts test/modules/apps/app-catalog-listing.test.ts) → 9 pass / 0 fail.

Risks

• minEngine: 0.6.6 will surface a "requires update" placeholder for any user still running a pre-0.6.6 engine. That is exactly the desired behavior — it matches the comment on the issue ("the minEngine gate … is armed on nothing"). The bundled entries still install on every released engine ≥ 0.6.6 because resolveCatalog falls back to the bundled copy when a too-new overlay overrides a bundled app; for users on a too-old engine, the placeholder guides them to upgrade instead of running the broken role.
• No schema change. minEngine already accepts any semver string and templateEngineOk already gates it. Pure data fix.

[Hydralerne]

thank you