slot-isolation: port and database axes are mandatory — a services-free project cannot declare a valid parallel_dev recipe #62

New issue

Open

opened 2026-08-25 08:18:05 +00:00 by jbr870 · 1 comment

jbr870 commented

2026-08-25 08:18:05 +00:00

Owner

Problem

The parallel_dev: recipe schema (slot-isolation.md §1) treats only the container axis as
omittable ("omit it and the axis is 'not declared'"). The port and database axes are
mandatory: slot-recipe-validate.sh refuses a recipe without port_scheme.base/block and
database.name_template/main_db.

A services-free project — no listeners, no databases — therefore cannot declare a valid slot
recipe at all, even though the worktree and container axes alone would serve it. It is forced to
either invent dummy port/DB values (recording identities that don't exist, which every later act
then dutifully "verifies") or abandon the slot machinery entirely.

Live case: devwork-skills itself (markdown+shell suite, observability: mode: none, no runtime
services) evaluated slots for its parallel-sessions setup on 2026-08-25 and had to route around the
skill — parallel sessions here now use Claude Code's built-in worktree flow instead (see CLAUDE.md
"Parallel sessions"). The skill lost a consumer to the schema, not to the concept.

Proposal

Make port_scheme: and database: omittable as whole blocks, mirroring the container axis
exactly:

Block absent → axis not-declared (terminal), other axes still provision, report carries
ports: not declared / database: not declared lines.
Block present → validated exactly as today (all current refusal rules unchanged — partial blocks
still refuse loudly naming the dotted path).
Consumers of the identity record (dev-server-lifecycle, QA playbook, retire) already handle
not-declared for the container axis; extend the same handling.

Lane

Full pipeline — validator behaviour (slot-recipe-validate.sh), the slot engines' axis handling,
and the normative schema in slot-isolation.md all change together.

## Problem The `parallel_dev:` recipe schema (slot-isolation.md §1) treats only the **container** axis as omittable ("omit it and the axis is 'not declared'"). The **port** and **database** axes are mandatory: `slot-recipe-validate.sh` refuses a recipe without `port_scheme.base`/`block` and `database.name_template`/`main_db`. A services-free project — no listeners, no databases — therefore **cannot declare a valid slot recipe at all**, even though the worktree and container axes alone would serve it. It is forced to either invent dummy port/DB values (recording identities that don't exist, which every later act then dutifully "verifies") or abandon the slot machinery entirely. Live case: devwork-skills itself (markdown+shell suite, `observability: mode: none`, no runtime services) evaluated slots for its parallel-sessions setup on 2026-08-25 and had to route around the skill — parallel sessions here now use Claude Code's built-in worktree flow instead (see CLAUDE.md "Parallel sessions"). The skill lost a consumer to the schema, not to the concept. ## Proposal Make `port_scheme:` and `database:` omittable **as whole blocks**, mirroring the container axis exactly: - Block absent → axis `not-declared` (terminal), other axes still provision, report carries `ports: not declared` / `database: not declared` lines. - Block present → validated exactly as today (all current refusal rules unchanged — partial blocks still refuse loudly naming the dotted path). - Consumers of the identity record (dev-server-lifecycle, QA playbook, retire) already handle `not-declared` for the container axis; extend the same handling. ## Lane Full pipeline — validator behaviour (`slot-recipe-validate.sh`), the slot engines' axis handling, and the normative schema in `slot-isolation.md` all change together.

jbr870 added the

labels

2026-08-25 08:18:05 +00:00

jbr870 referenced this issue

2026-08-25 08:52:48 +00:00

git-worktrees: defer bare-worktree requests to the harness's native worktree flow — the skill is for provisioned parallel dev only #63

jbr870 commented

2026-08-25 09:26:47 +00:00

Author

Owner

Recurrence evidence (2026-08-25, parallel-wave-1, session devwork-43): with the repo now
running harness-native worktrees (git worktree list shows linked worktrees), readiness-check.md
conditionally requires a parallel_dev: declaration — which this repo deliberately cannot and
should not write (nothing to provision; parallel sessions use the harness flow per CLAUDE.md
"Parallel sessions"). So the schema gap now also manifests as a standing readiness nag on any
project that parallelizes via bare worktrees. Whatever shape the fix takes (omittable axes per this
issue's proposal, or a readiness carve-out for the harness-native flow), it should silence that nag
for provisioning-free projects rather than teach them to declare dummy axes.

**Recurrence evidence (2026-08-25, parallel-wave-1, session devwork-43):** with the repo now running harness-native worktrees (`git worktree list` shows linked worktrees), `readiness-check.md` conditionally requires a `parallel_dev:` declaration — which this repo deliberately cannot and should not write (nothing to provision; parallel sessions use the harness flow per CLAUDE.md "Parallel sessions"). So the schema gap now also manifests as a **standing readiness nag** on any project that parallelizes via bare worktrees. Whatever shape the fix takes (omittable axes per this issue's proposal, or a readiness carve-out for the harness-native flow), it should silence that nag for provisioning-free projects rather than teach them to declare dummy axes.

jbr870 referenced this issue

2026-08-25 10:23:53 +00:00

QA: intra-run lane-ownership primitive, plus a void-vs-flaky triage rule #43

jbr870 referenced this issue

2026-08-25 10:33:04 +00:00

devcontainer: refresh for the plugin era — per-container claude state, worktree plugin wiring, parallel-safe compose naming #61

jbr870 referenced this issue

2026-08-25 10:37:17 +00:00

QA: intra-run lane-ownership primitive, plus a void-vs-flaky triage rule #43

jbr870 referenced this issue

2026-08-25 14:01:54 +00:00

release-pipeline-status.sh --ref returns a stale pipeline — a false green immediately before a production tag #47