Automatically prepare releases for completed features

.dockerignore

@@ -1,27 +0,0 @@
-# Keep the image build context minimal: only api/ and the bundled
-# custom_components/nestquest/core/ are copied (see the Dockerfile);
-# everything else — VCS state, virtualenvs, tests, the frontend, and
-# any local secrets or database files — never enters the build.
-.git
-.gitignore
-.venv
-**/__pycache__
-**/*.py[cod]
-.pytest_cache
-**/*.db
-**/*.db-wal
-**/*.db-shm
-# Local configuration — never baked into an image.
-.env
-**/.env
-deploy
-design
-docs
-frontend
-orchestration_tests
-scripts
-templates
-tests
-uv.lock
-hacs.json
-*.md

.gitignore

@@ -5,12 +5,3 @@ __pycache__/
 .pytest_cache/
 *.metadata.json
 frontend/node_modules/
-
-# Feature 17 (API deployment): local secret config and runtime data
-# are never committed — compose reads deploy/.env; SQLite/WAL sidecar
-# files are container/volume artifacts.
-.env
-**/.env
-*.db
-*.db-wal
-*.db-shm

Dockerfile

@@ -1,47 +0,0 @@
-# Container image for the NestQuest API service (Feature 17).
-#
-# Build context is the REPOSITORY ROOT (compose sets it), because the
-# API loads the bundled domain layer from
-# custom_components/nestquest/core/ by file location
-# (api/nestquest_core.py): the image must carry both api/ and the
-# bundled core at their relative positions.  Everything else in the
-# repository is excluded via .dockerignore.
-#
-# Multi-stage so no pip/build toolchain survives into the runtime:
-# the builder installs the deployable's own manifest
-# (api/requirements.txt) into a staging prefix and the runtime copies
-# only the installed packages.  The service runs as a non-root user;
-# the SQLite database lives on the mounted volume at
-# /var/lib/nestquest (compose supplies NESTQUEST_DB_PATH pointing
-# there — configuration is environment-supplied, never baked in).
-FROM python:3.12-slim AS builder
-
-COPY api/requirements.txt /tmp/requirements.txt
-RUN pip install --no-cache-dir --prefix=/install -r /tmp/requirements.txt
-
-FROM python:3.12-slim
-
-# The staged dependency install from the builder (no pip, no wheels).
-COPY --from=builder /install /usr/local
-
-# /app is the repository-root equivalent: api/ resolves imports as
-# ``api.*`` and nestquest_core.py finds the bundled core one level up.
-WORKDIR /app
-COPY api/ ./api/
-COPY custom_components/nestquest/core/ ./custom_components/nestquest/core/
-
-# Non-root runtime user; owns the database volume mount point.
-RUN useradd --system --create-home --home-dir /home/nestquest nestquest \
-    && mkdir -p /var/lib/nestquest \
-    && chown nestquest:nestquest /var/lib/nestquest
-USER nestquest
-
-ENV PYTHONUNBUFFERED=1 PYTHONDONTWRITEBYTECODE=1
-
-# The database path and the service token / OIDC settings are supplied
-# by the environment (compose env_file), never committed into the image.
-ENV NESTQUEST_DB_PATH=/var/lib/nestquest/nestquest.db
-VOLUME /var/lib/nestquest
-
-EXPOSE 8080
-CMD ["uvicorn", "--factory", "api.app:create_app", "--host", "0.0.0.0", "--port", "8080"]

api/README.md

@@ -1,32 +0,0 @@
-# NestQuest API
-
-Standalone FastAPI service owning the NestQuest database (Feature 16).
-Served with ``uvicorn --factory api.app:create_app``; configuration is
-environment-supplied (``api/config.py``) and every variable is required.
-
-## Runtime dependencies
-
-``api/requirements.txt`` is the API deployable's OWN dependency
-manifest (fastapi, uvicorn, pyjwt[crypto], httpx) — deliberately kept
-out of the integration's ``pyproject.toml`` dev group, which exists only
-so the monorepo test venv can run the API tests.
-
-## Container deployment (scaffold)
-
-The image is built from the repository ROOT context (the API loads the
-bundled domain core from ``custom_components/nestquest/core/`` by file
-location, so both trees must be in the build context):
-
-    docker build -t nestquest-api:latest .
-
-Run it with compose — the SQLite file lives on the named volume
-``nestquest-db`` so recreating the container keeps household data:
-
-    cp deploy/.env.example deploy/.env   # then fill in real values
-    docker compose -f deploy/compose.yaml up -d --build
-
-``deploy/.env`` is git-ignored and supplies the secrets (panel service
-token, Authentik OIDC settings); ``NESTQUEST_DB_PATH`` is fixed to
-``/var/lib/nestquest/nestquest.db`` by compose. The port is bound to
-localhost only — TLS/reverse proxy, Authentik, network separation,
-backup and restore are later Feature 17 tasks.

api/requirements.txt

@@ -1,15 +0,0 @@
-# Runtime dependency manifest for the NestQuest API deployable.
-#
-# The monorepo's pyproject.toml carries fastapi/uvicorn/pyjwt/httpx in
-# the INTEGRATION's dev group only (so the test venv can exercise the
-# API); they are deliberately NOT integration runtime dependencies.
-# Per that manifest's own comment, the API deployable declares its own
-# runtime dependencies HERE — this file is what the container image
-# installs (see the Dockerfile at the repository root).
-#
-# Compatible ranges mirroring the dev group's floors; the API is a
-# server, so these are the only packages its runtime needs.
-fastapi>=0.115
-uvicorn>=0.30
-pyjwt[crypto]>=2.9
-httpx>=0.28

deploy/.env.example

@@ -1,17 +0,0 @@
-# Example environment for the NestQuest API container deployment.
-#
-# Copy to ``deploy/.env`` (git-ignored) and fill in REAL values there;
-# this example carries placeholder names only and is never a source of
-# secrets.  Compose loads ``deploy/.env`` into the api service; the
-# API fails fast on startup when any of these is unset or empty
-# (api/config.py — there are no silent defaults).
-
-# The static panel-plane service token the HA integration presents as
-# a Bearer credential on /api/v1/panel/* routes. Generate one, e.g.:
-#   python -c "import secrets; print(secrets.token_urlsafe(32))"
-NESTQUEST_PANEL_TOKEN=
-
-# The Authentik OIDC settings the admin plane verifies JWTs against.
-NESTQUEST_OIDC_ISSUER=
-NESTQUEST_OIDC_AUDIENCE=
-NESTQUEST_OIDC_JWKS_URL=

deploy/compose.yaml

@@ -1,41 +0,0 @@
-# Compose deployment scaffold for the NestQuest API service (Feature
-# 17).  The SQLite database lives on the NAMED VOLUME ``nestquest-db``
-# mounted at /var/lib/nestquest — recreating the container keeps the
-# household data (``docker compose down`` leaves named volumes alone).
-#
-# Configuration is supplied by the environment: the fixed database
-# path here, and the secret values (panel service token, Authentik
-# OIDC settings) from ``deploy/.env`` — a git-ignored file you create
-# from ``deploy/.env.example`` (placeholder names only; never commit
-# real values).  TLS/reverse proxy, Authentik wiring and network
-# separation are later Feature 17 tasks; the port is bound to
-# localhost only until those land.
-services:
-  api:
-    build:
-      context: ..
-      dockerfile: Dockerfile
-    image: nestquest-api:latest
-    init: true
-    restart: unless-stopped
-    ports:
-      - "127.0.0.1:8080:8080"
-    environment:
-      # The SQLite file inside the named volume; fixed, not a secret.
-      NESTQUEST_DB_PATH: /var/lib/nestquest/nestquest.db
-    env_file:
-      # Secret values (NESTQUEST_PANEL_TOKEN, NESTQUEST_OIDC_*); absent
-      # until you create deploy/.env from the example.
-      - path: .env
-        required: false
-    volumes:
-      - nestquest-db:/var/lib/nestquest
-    healthcheck:
-      test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8080/health')"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-      start_period: 15s
-
-volumes:
-  nestquest-db:

orchestration_tests/test_cycle_prompt.py

@@ -51,6 +51,30 @@ class CyclePromptTests(unittest.TestCase):
         self.assertNotIn("The persistent user service runs", output)
         self.assertNotIn("---\n\n---\n\n# 27", output)
 
+    def test_task_complete_feature_triggers_one_guarded_promotion(self):
+        output = RENDER(TEMPLATE, PROFILE)
+        self.assertIn(
+            "feature becomes task-complete and its reviewed merge into `dev` is verified",
+            output,
+        )
+        self.assertIn("Task completion inside an unmerged feature branch does not trigger", output)
+        self.assertIn("Do not create a duplicate promotion", output)
+        self.assertIn("Allow only one active promotion pull request to `main`", output)
+        self.assertIn("if it was closed without merge, recalculate", output)
+        self.assertIn("sole active orchestrator for the project", output)
+        self.assertIn("including controller exclusivity, reconciliation", output)
+        self.assertIn("RELEASE_PREPARATION_POLICY = EXCLUDED", output)
+        self.assertIn("Active promotion branch and pull request", output)
+        self.assertIn("An active promotion that has not reached `RELEASE_READY`", output)
+        self.assertIn("RELEASE_PREPARATION_POLICY:\n", output)
+        self.assertIn("A ready promotion is a local checkpoint", output)
+        self.assertIn("continue that work while the ready promotion waits", output)
+        self.assertLess(
+            output.index("Begin an automatically triggered, requested, or scheduled release"),
+            output.index("Advance to the next eligible feature"),
+        )
+        self.assertIn("Only Joshua may merge into `main`", output)
+
 
 if __name__ == "__main__":
     unittest.main()

templates/ORCHESTRATOR-PROMPT.template.md

@@ -150,6 +150,15 @@ Possible scopes:
 - `PROJECT_QUEUE`
 - `RELEASE_PREPARATION`
 
+Also set `RELEASE_PREPARATION_POLICY` at startup:
+
+- `AUTO` by default.
+- `EXCLUDED` only when the user's launch request explicitly says not to prepare
+  a release or `{{INTEGRATION_BRANCH}}`-to-`{{RELEASE_BRANCH}}` promotion.
+
+Record both `MISSION_SCOPE` and `RELEASE_PREPARATION_POLICY` in durable run
+state. Do not infer exclusion merely from `SINGLE_TASK` or `SINGLE_FEATURE`.
+
 If the user explicitly names one task or feature, respect that scope.
 
 If the user launches the orchestrator for general/autonomous {{PROJECT_NAME}} development without limiting it to one feature, use:
@@ -171,6 +180,7 @@ Maintain a durable orchestration checkpoint using {{WORK_TRACKER}} wherever its
 Track at minimum:
 
 - `MISSION_SCOPE`
+- `RELEASE_PREPARATION_POLICY`
 - Current feature
 - Current controller phase
 - Active development agents
@@ -185,6 +195,9 @@ Track at minimum:
 - Blocked items
 - Tests/checks status
 - Last verified repository state
+- Active promotion branch and pull request
+- Triggering feature and exact `{{INTEGRATION_BRANCH}}` commit for each automatic promotion
+- Completed features pending the next promotion
 - `NEXT_ACTION`
 
 After every material state transition:
@@ -254,8 +267,8 @@ Choose the highest-priority actionable transition in this order:
 8. Remediate feature-level review findings.
 9. Obtain feature approval.
 10. Merge an approved feature into `{{INTEGRATION_BRANCH}}`.
-11. Advance to the next eligible feature when mission scope permits.
-12. Begin a requested/scheduled release when appropriate.
+11. Begin an automatically triggered, requested, or scheduled release when appropriate. The automatic post-feature trigger is in scope for both `SINGLE_FEATURE` and `PROJECT_QUEUE` unless `RELEASE_PREPARATION_POLICY = EXCLUDED`.
+12. Advance to the next eligible feature when mission scope permits.
 13. Continue unrelated work around locally blocked items.
 14. Escalate only when the defined escalation rules require it.
 
@@ -588,9 +601,10 @@ Immediately transition to `FEATURE_INTEGRATION`.
 
 A merged feature is a transition.
 
-It is terminal ONLY when:
-
-`MISSION_SCOPE = SINGLE_FEATURE`
+It is terminal only when `MISSION_SCOPE = SINGLE_FEATURE` and no authorized
+post-feature release transition is pending. Preparing the automatic promotion
+for that completed feature is part of `SINGLE_FEATURE` scope when
+`RELEASE_PREPARATION_POLICY = AUTO`.
 
 Otherwise select the next eligible work.
 
@@ -637,13 +651,19 @@ The orchestrator itself does not perform the merge.
 When `MISSION_SCOPE = PROJECT_QUEUE` and a feature is successfully merged into `{{INTEGRATION_BRANCH}}`:
 
 1. Reconcile {{WORK_TRACKER}}.
-2. Check for a requested/scheduled release.
+2. Evaluate the automatic, requested, and scheduled release triggers.
 3. Identify remaining incomplete features.
 4. Determine which features are eligible based on dependencies and priority.
 5. Select the next eligible feature.
 6. Initialize it.
 7. Continue the development loop.
 
+If an automatic promotion becomes `RELEASE_READY` while another eligible
+feature remains, keep that promotion waiting for {{RELEASE_OWNER_NAME}} and
+continue the project queue. A ready promotion is a local checkpoint in this
+case, not a global terminal condition. Features completed while it remains open
+are recorded as pending for the next promotion under Section 18.
+
 Do not return to the user simply because one feature completed.
 
 If several features are available, choose using:
@@ -658,27 +678,52 @@ If several features are available, choose using:
 
 # 18. RELEASE RULES
 
-Completed features accumulate in `{{INTEGRATION_BRANCH}}`.
+Completed features accumulate in `{{INTEGRATION_BRANCH}}`. With no active
+promotion, each verified feature completion starts release preparation. While
+one promotion is active, later completed features accumulate for the next
+promotion.
 
-Prepare a release only when:
+Prepare a release when any of these conditions is true:
 
 - {{RELEASE_OWNER_NAME}} requests it; OR
-- {{WORK_TRACKER}} schedules it.
+- {{WORK_TRACKER}} schedules it; OR
+- `RELEASE_PREPARATION_POLICY = AUTO`, and a feature becomes task-complete and its reviewed merge into `{{INTEGRATION_BRANCH}}` is verified.
+
+For the automatic trigger, a feature is task-complete only when:
+
+- Every required feature task is `done`, or deliberately `canceled` with recorded evidence.
+- No task review, remediation, approval, or merge remains pending.
+- The feature acceptance criteria and integrated checks pass.
+- Independent approval applies to the exact feature head.
+- The approver's merge of that head into `{{INTEGRATION_BRANCH}}` is verified.
+- {{WORK_TRACKER}} reflects the completed feature and exact repository references.
+
+Task completion inside an unmerged feature branch does not trigger a release.
+The verified feature-to-`{{INTEGRATION_BRANCH}}` merge is the triggering transition.
+
+Before creating a release branch or pull request:
+
+1. Verify this session is the sole active orchestrator for the project. `{{TERMINAL_LAUNCHER}}` must enforce that exclusivity. If sole ownership cannot be verified, do not create a release branch or pull request; escalate instead.
+2. Reconcile open release records, release branches, and promotion pull requests.
+3. Do not create a duplicate promotion for an already-covered `{{INTEGRATION_BRANCH}}` commit.
+4. Allow only one active promotion pull request to `{{RELEASE_BRANCH}}`. If an earlier promotion is still open and does not contain the newly completed feature, record the feature as pending for the next automatic promotion. Resume it after the active promotion is merged or closed; if it was closed without merge, recalculate the next promotion from the current validated `{{INTEGRATION_BRANCH}}` head.
+5. Record the triggering feature and exact `{{INTEGRATION_BRANCH}}` commit so the automatic trigger runs once for that merge.
 
 Release process:
 
-1. Reconcile release scope.
-2. Confirm included features are complete.
-3. Create release branch from exact validated `{{INTEGRATION_BRANCH}}`.
-4. Run complete release checks.
-5. Open release PR → `{{RELEASE_BRANCH}}`.
-6. Obtain fresh independent {{REVIEWER_VENDOR}} review.
-7. Remediate findings through development agents.
-8. Incorporate every release correction back into `{{INTEGRATION_BRANCH}}`.
-9. Revalidate.
-10. Assign final release PR to `{{HOST_ACCOUNT}}`.
-11. Update {{WORK_TRACKER}}.
-12. Stop before {{RELEASE_BRANCH}} merge.
+1. Enforce every pre-creation requirement above, including controller exclusivity, reconciliation, duplicate and active-promotion checks, and trigger recording.
+2. Reconcile release scope.
+3. Confirm included features are complete.
+4. Create release branch from exact validated `{{INTEGRATION_BRANCH}}`.
+5. Run complete release checks.
+6. Open release PR → `{{RELEASE_BRANCH}}`.
+7. Obtain fresh independent {{REVIEWER_VENDOR}} review.
+8. Remediate findings through development agents.
+9. Incorporate every release correction back into `{{INTEGRATION_BRANCH}}`.
+10. Revalidate.
+11. Assign final release PR to `{{HOST_ACCOUNT}}`.
+12. Update {{WORK_TRACKER}}.
+13. Stop before {{RELEASE_BRANCH}} merge.
 
 Only {{RELEASE_OWNER_NAME}} may merge into `{{RELEASE_BRANCH}}`.
 
@@ -724,13 +769,23 @@ For `PROJECT_QUEUE`, this additionally requires:
 
 - No eligible incomplete feature remains.
 - No task/review/remediation/merge is pending.
+- No release preparation, release review, or release remediation is pending.
+- Every in-scope automatic trigger is either incorporated into the active
+  `RELEASE_READY` promotion or durably recorded for the next promotion.
 - No development agent is active.
 - No approver is active.
 
+An active promotion that has not reached `RELEASE_READY` makes
+`MISSION_COMPLETE` false.
+
 ## `RELEASE_READY`
 
 Release PR has passed required gates and is assigned to `{{HOST_ACCOUNT}}`, awaiting {{RELEASE_OWNER_NAME}}'s {{RELEASE_BRANCH}} merge.
 
+`RELEASE_READY` is globally terminal only when no other in-scope engineering
+action is executable. In `PROJECT_QUEUE`, if another eligible incomplete
+feature remains, continue that work while the ready promotion waits.
+
 ## `GLOBAL_ESCALATION`
 
 All remaining in-scope work is blocked by decisions/access that require {{RELEASE_OWNER_NAME}}.
@@ -778,9 +833,12 @@ Output a machine-readable continuation checkpoint:
 ```text
 ORCHESTRATOR_STATE: CONTINUE
 MISSION_SCOPE:
+RELEASE_PREPARATION_POLICY:
 CONTROLLER_PHASE:
 CURRENT_FEATURE:
 ACTIVE_TASKS:
+ACTIVE_PROMOTION:
+PENDING_PROMOTION_FEATURES:
 BLOCKED_ITEMS:
 LAST_VERIFIED_STATE:
 NEXT_ACTION: