@laitszkin/apollo-toolkit 2.8.0 → 2.9.0

package/CHANGELOG.md

@@ -4,6 +4,12 @@ All notable changes to this repository are documented in this file.
 
 ## [Unreleased]
 
+## [v2.9.0] - 2026-03-21
+
+### Changed
+- Update `scheduled-runtime-health-check` to run requested commands in a background terminal immediately or within a requested time window, with optional pre-run safe updates and optional post-run log findings.
+- Update `open-github-issue` to require explicit BDD-style expected behavior, current behavior, and behavior-gap content for problem issues, and enforce that contract in the bundled publisher script and docs.
+
 ## [v2.8.0] - 2026-03-21
 
 ### Changed

package/open-github-issue/README.md

@@ -42,7 +42,7 @@ The bundled script can also be called directly:
 python scripts/open_github_issue.py \
   --issue-type problem \
   --title "[Log] Payment timeout spike" \
-  --problem-description "Repeated timeout warnings escalated into request failures during the incident window." \
+  --problem-description $'Expected Behavior (BDD)\nGiven the payment service sees transient upstream latency\nWhen the retry path runs\nThen requests should recover without user-visible failures\n\nCurrent Behavior (BDD)\nGiven the payment service sees transient upstream latency\nWhen the retry path runs\nThen repeated timeout warnings still escalate into request failures\n\nBehavior Gap\n- Expected: retries absorb transient upstream slowness.\n- Actual: retries still end in request failures.\n- Difference/Impact: customers receive failed payment attempts during the incident window.\n\nEvidence\n- symptom: repeated timeout warnings escalated into request failures.\n- impact: payment attempts failed for end users.\n- key evidence: logs from the incident window show retries without successful recovery.' \
   --suspected-cause "payment-api/handler.py:84 retries immediately against a slow upstream with no jitter; confidence high." \
   --reproduction "Not yet reliably reproducible; more runtime evidence is required." \
   --repo owner/repo
@@ -72,6 +72,12 @@ Problem issues always include exactly three sections:
 - `Suspected Cause`
 - `Reproduction Conditions (if available)`
 
+Within `Problem Description`, include:
+
+- `Expected Behavior (BDD)`
+- `Current Behavior (BDD)`
+- `Behavior Gap`
+
 For Chinese-language repositories, use translated section titles with the same meaning.
 
 Feature proposal issues always include:

package/open-github-issue/SKILL.md

@@ -14,9 +14,9 @@ description: Publish structured GitHub issues and feature proposals with determi
 
 ## Standards
 
-- Evidence: Require structured issue inputs and detect repository language from the target README instead of guessing.
+- Evidence: Require structured issue inputs, detect repository language from the target README instead of guessing, and for `problem` issues capture BDD-style expected vs current behavior with an explicit delta.
 - Execution: Resolve the repo, normalize the issue body, publish with strict auth order, then return the publication result.
-- Quality: Preserve upstream evidence, localize only the structural parts, and keep publication deterministic and reproducible.
+- Quality: Preserve upstream evidence, localize only the structural parts, keep publication deterministic and reproducible, and make behavioral mismatches easy for maintainers to verify.
 - Output: Return publication mode, issue URL when created, rendered body, and any publish error in the standardized JSON contract.
 
 ## Overview
@@ -37,6 +37,7 @@ It is designed to be reusable by other skills that already know the issue title
 - Detect repository issue language from the target remote README instead of guessing.
 - Preserve upstream evidence content; only localize section headers and default fallback text.
 - Make the issue type explicit: `problem` for defects/incidents, `feature` for proposals.
+- For `problem` issues, describe the expected behavior and current behavior with BDD-style `Given / When / Then`, then state the behavioral difference explicitly.
 
 ## Workflow
 
@@ -49,6 +50,11 @@ It is designed to be reusable by other skills that already know the issue title
      - `problem-description`
      - `suspected-cause`
      - `reproduction` (optional)
+   - Within `problem-description`, require a precise behavior diff:
+     - `Expected Behavior (BDD)`: `Given / When / Then` for what the program should do.
+     - `Current Behavior (BDD)`: `Given / When / Then` for what the program does now.
+     - `Behavior Gap`: a short explicit comparison of the observable difference and impact.
+     - Include the symptom, impact, and key evidence alongside the behavior diff; do not leave the mismatch implicit.
    - For `feature` issues, require these structured sections:
      - `proposal` (optional; defaults to title when omitted)
      - `reason`
@@ -74,7 +80,7 @@ Problem issue:
 python scripts/open_github_issue.py \
   --issue-type problem \
   --title "[Log] <short symptom>" \
-  --problem-description "<symptom + impact + key evidence>" \
+  --problem-description $'Expected Behavior (BDD)\nGiven ...\nWhen ...\nThen ...\n\nCurrent Behavior (BDD)\nGiven ...\nWhen ...\nThen ...\n\nBehavior Gap\n- Expected: ...\n- Actual: ...\n- Difference/Impact: ...\n\nEvidence\n- symptom: ...\n- impact: ...\n- key evidence: ...' \
   --suspected-cause "<path:line + causal chain + confidence>" \
   --reproduction "<steps/conditions or leave empty>" \
   --repo <owner/repo>
@@ -111,6 +117,7 @@ When another skill depends on `open-github-issue`:
 
 - Pass exactly one confirmed problem or one accepted feature proposal per invocation.
 - Prepare evidence or proposal details before calling this skill; do not ask this skill to infer root cause or architecture.
+- For `problem` issues, pass a `problem-description` that contains `Expected Behavior (BDD)`, `Current Behavior (BDD)`, and `Behavior Gap`; the difference must be explicit, not implied.
 - Reuse the returned `mode`, `issue_url`, and `publish_error` in the parent skill response.
 - For accepted feature proposals, pass `--issue-type feature` plus `--proposal`, `--reason`, and `--suggested-architecture`.
 

package/open-github-issue/scripts/open_github_issue.py

@@ -19,6 +19,18 @@ DEFAULT_REPRO_ZH = "尚未穩定重現；需補充更多執行期資料。"
 DEFAULT_REPRO_EN = "Not yet reliably reproducible; more runtime evidence is required."
 ISSUE_TYPE_PROBLEM = "problem"
 ISSUE_TYPE_FEATURE = "feature"
+PROBLEM_BDD_MARKER_GROUPS = (
+    (
+        r"Expected Behavior\s*\(BDD\)",
+        r"Current Behavior\s*\(BDD\)",
+        r"Behavior Gap",
+    ),
+    (
+        r"預期行為\s*[（(]BDD[）)]",
+        r"(?:目前|當前)行為\s*[（(]BDD[）)]",
+        r"行為(?:落差|差異)",
+    ),
+)
 
 
 def parse_args() -> argparse.Namespace:
@@ -83,6 +95,19 @@ def validate_issue_content_args(args: argparse.Namespace) -> None:
         raise SystemExit("Problem issues require --problem-description.")
     if not (args.suspected_cause or "").strip():
         raise SystemExit("Problem issues require --suspected-cause.")
+    if not has_required_problem_bdd_sections(args.problem_description or ""):
+        raise SystemExit(
+            "Problem issues require --problem-description to include "
+            "Expected Behavior (BDD), Current Behavior (BDD), and Behavior Gap sections."
+        )
+
+
+def has_required_problem_bdd_sections(problem_description: str) -> bool:
+    normalized = problem_description.strip()
+    return any(
+        all(re.search(pattern, normalized, flags=re.IGNORECASE) for pattern in marker_group)
+        for marker_group in PROBLEM_BDD_MARKER_GROUPS
+    )
 
 
 def run_command(args: list[str]) -> subprocess.CompletedProcess[str]:

package/open-github-issue/tests/test_open_github_issue.py

@@ -121,11 +121,59 @@ class OpenGitHubIssueTests(unittest.TestCase):
             )
         )
 
+    def test_validate_issue_content_args_requires_problem_bdd_sections(self) -> None:
+        with self.assertRaises(SystemExit):
+            MODULE.validate_issue_content_args(
+                Namespace(
+                    issue_type=MODULE.ISSUE_TYPE_PROBLEM,
+                    reason=None,
+                    suggested_architecture=None,
+                    problem_description="Repeated timeout warnings escalated into request failures.",
+                    suspected_cause="handler.py:12",
+                )
+            )
+
+        MODULE.validate_issue_content_args(
+            Namespace(
+                issue_type=MODULE.ISSUE_TYPE_PROBLEM,
+                reason=None,
+                suggested_architecture=None,
+                problem_description=(
+                    "Expected Behavior (BDD)\n"
+                    "Given requests arrive during transient upstream latency\n"
+                    "When the retry path runs\n"
+                    "Then the request should recover without user-visible failure\n\n"
+                    "Current Behavior (BDD)\n"
+                    "Given requests arrive during transient upstream latency\n"
+                    "When the retry path runs\n"
+                    "Then the request still fails after immediate retries\n\n"
+                    "Behavior Gap\n"
+                    "- Expected: retries absorb transient slowness.\n"
+                    "- Actual: retries amplify failures.\n"
+                    "- Difference/Impact: users still receive errors.\n"
+                ),
+                suspected_cause="handler.py:12",
+            )
+        )
+
     def test_main_dry_run_returns_structured_json_without_publish_attempt(self) -> None:
         args = Namespace(
             title="[Log] sample",
             issue_type=MODULE.ISSUE_TYPE_PROBLEM,
-            problem_description="problem",
+            problem_description=(
+                "Expected Behavior (BDD)\n"
+                "Given the issue is confirmed\n"
+                "When the issue body is rendered\n"
+                "Then the expected path should be explicit\n\n"
+                "Current Behavior (BDD)\n"
+                "Given the issue is confirmed\n"
+                "When the issue body is rendered\n"
+                "Then the current path should be explicit\n\n"
+                "Behavior Gap\n"
+                "- Expected: clear behavior diff.\n"
+                "- Actual: sample payload for dry run.\n"
+                "- Difference/Impact: contract stays structured.\n"
+            ),
             suspected_cause="handler.py:12",
             reproduction=None,
             proposal=None,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@laitszkin/apollo-toolkit",
-  "version": "2.8.0",
+  "version": "2.9.0",
   "description": "Apollo Toolkit npm installer for managed skill copying across Codex, OpenClaw, and Trae.",
   "license": "MIT",
   "author": "LaiTszKin",

package/scheduled-runtime-health-check/README.md

@@ -1,15 +1,16 @@
 # Scheduled Runtime Health Check
 
-An agent skill for scheduled, bounded project runs with post-run health analysis.
+An agent skill for running user-requested commands in a background terminal, optionally inside a bounded time window with post-run log analysis.
 
-This skill helps agents start a project at a chosen time, keep it alive for a fixed observation window, stop it automatically, collect the relevant logs, and summarize module health with evidence-backed findings from `analyse-app-logs`.
+This skill helps agents use a background terminal to run a requested command immediately or in a chosen time window, and optionally summarize evidence-backed findings from the resulting logs via `analyse-app-logs`.
 
 ## What this skill provides
 
-- A workflow for one-off or recurring runtime health checks.
+- A workflow for one-off or recurring background-terminal runtime checks.
+- An optional code-update step before execution.
 - Clear separation between scheduling, runtime observation, shutdown, and diagnosis.
 - A bounded log window so startup, steady-state, and shutdown evidence stay correlated.
-- Module-level health classification: `healthy`, `degraded`, `failed`, or `unknown`.
+- Optional module-level health classification: `healthy`, `degraded`, `failed`, or `unknown`.
 - Escalation to `improve-observability` when existing telemetry is insufficient.
 
 ## Repository structure
@@ -33,22 +34,28 @@ cp -R scheduled-runtime-health-check "$CODEX_HOME/skills/scheduled-runtime-healt
 Invoke the skill in your prompt:
 
 ```text
-Use $scheduled-runtime-health-check to start this project at 22:00, keep it running for 6 hours, stop it automatically, and analyze whether the API, worker, and scheduler modules stayed healthy.
+Use $scheduled-runtime-health-check to use a background terminal to run `docker compose up app worker`.
+
+Run it in this specific time window: 2026-03-18 22:00 to 2026-03-19 04:00 Asia/Hong_Kong.
+
+After the run completes, explain your findings from the logs.
 ```
 
 Best results come from including:
 
 - workspace path
-- start command
+- execution command
 - stop command or acceptable shutdown method
-- schedule and timezone
-- duration
+- schedule/time window and timezone
+- duration when bounded
 - readiness signal
 - relevant log files
-- modules or subsystems to assess
+- modules or subsystems to assess when findings are requested
+- whether the repository should be updated first, only if you want that behavior
 
 If no trustworthy start command is documented, the agent should derive it from the repository or ask only for that missing command.
 If the user requests a future start time and no reliable scheduler is available, the agent should report that limitation instead of starting the run early.
+If an optional update step was requested but the repository cannot be updated safely because the worktree is dirty or no upstream is configured, the agent should stop and report that exact blocker instead of forcing an update.
 
 ## Example
 
@@ -58,13 +65,14 @@ If the user requests a future start time and no reliable scheduler is available,
 Use $scheduled-runtime-health-check for this repository.
 
 Workspace: /workspace/my-app
-Start command: docker compose up app worker
+Execution command: docker compose up app worker
 Stop command: docker compose down
 Schedule: 2026-03-18 22:00 Asia/Hong_Kong
 Duration: 6 hours
 Readiness signal: GET http://127.0.0.1:3000/health returns 200
 Logs: docker compose logs, logs/app.log, logs/worker.log
 Modules to assess: api, worker, scheduler
+After completion: explain findings from the logs
 ```
 
 ### Expected response shape
@@ -73,21 +81,24 @@ Modules to assess: api, worker, scheduler
 1) Run summary
 - Started at 2026-03-18 22:00 HKT and stopped at 2026-03-19 04:00 HKT after a 6-hour bounded run.
 
-2) Module health
+2) Execution result
+- The background terminal completed the requested run workflow and kept the services up for the full window.
+
+3) Module health
 - api: healthy, served readiness checks and no error bursts were observed.
 - worker: degraded, repeated timeout warnings increased after 01:20 HKT.
 - scheduler: unknown, no positive execution signal was emitted during the window.
 
-3) Confirmed issues
+4) Confirmed issues
 - Reuse evidence-backed findings from $analyse-app-logs.
 
-4) Potential issues and validation needed
+5) Potential issues and validation needed
 - Scheduler may not be firing jobs; add a per-job execution log or metric to confirm.
 
-5) Observability gaps
+6) Observability gaps
 - Missing correlation IDs between api requests and worker jobs.
 
-6) Automation or scheduler status
+7) Automation or scheduler status
 - One bounded scheduled run completed and no further cleanup is required.
 ```
 

package/scheduled-runtime-health-check/SKILL.md

@@ -1,40 +1,51 @@
 ---
 name: scheduled-runtime-health-check
-description: Coordinate a scheduled, bounded project run that starts automatically, stays up for a fixed observation window, stops cleanly, and delegates log-based health analysis to analyse-app-logs. Use when users want timed project startups, post-run health checks across modules, and a report of confirmed issues and potential risks.
+description: Use a background terminal to run a user-specified command immediately or in a requested time window, and optionally explain findings from the captured logs after the run. Use when users want timed project execution, bounded runtime checks, or post-run log-based findings.
 ---
 
 # Scheduled Runtime Health Check
 
 ## Dependencies
 
-- Required: `analyse-app-logs` for bounded post-run log analysis.
+- Required: `analyse-app-logs` when the user asks for post-run log findings or when the observed run needs evidence-backed diagnosis.
 - Conditional: `improve-observability` when current logs cannot prove module health or root cause.
 - Optional: `open-github-issue` indirectly through `analyse-app-logs` when confirmed issues should be published.
 - Fallback: If no scheduler or automation capability is available for the requested future start time, stop and report that scheduling could not be created; only run immediately when the user explicitly allows an immediate bounded observation instead of a timed start.
 
 ## Standards
 
-- Evidence: Anchor every conclusion to the scheduled window, startup/shutdown timestamps, captured logs, and concrete module signals.
-- Execution: Collect the run contract, choose a scheduling mechanism, capture logs, run for a bounded window, stop cleanly, then delegate the review to `analyse-app-logs`.
-- Quality: Keep scheduling and shutdown deterministic, separate confirmed findings from hypotheses, and mark each module healthy/degraded/failed/unknown with reasons.
-- Output: Return the run configuration, module health by area, confirmed issues, potential issues, observability gaps, and automation or scheduler status.
+- Evidence: Anchor every conclusion to the requested command, execution window, startup/shutdown timestamps, captured logs, and concrete runtime signals.
+- Execution: Collect the run contract, use a background terminal, optionally update the code only when the user asks, execute the requested command immediately or in the requested window, capture logs, stop cleanly when bounded, then delegate log review to `analyse-app-logs` only when findings are requested or needed.
+- Quality: Keep scheduling, execution, and shutdown deterministic; separate confirmed findings from hypotheses; and mark each assessed module healthy/degraded/failed/unknown with reasons.
+- Output: Return the run configuration, execution status, log locations, optional code-update result, optional module health by area, confirmed issues, potential issues, observability gaps, and scheduler status when applicable.
 
 ## Overview
 
-Use this skill when the user wants an agent to:
+Use this skill when the user wants an agent to do work in this shape:
 
-- start a project at a specific time
-- keep it running for a fixed window such as 6 hours
-- stop it automatically at the end of that window
-- collect logs from startup through shutdown
-- assess whether key modules behaved normally
-- identify confirmed problems and potential risks from the observed run
+- use a background terminal for the whole run
+- execute a specific command such as `npm run dev`, `docker compose up`, or another repo-defined entrypoint
+- optionally update the project before execution when the user explicitly asks
+- optionally run it inside a specific time window
+- optionally wait for the run to finish and then explain findings from the logs
 
-This skill is an orchestration layer. It owns the schedule, bounded runtime, log capture, and module-level health summary. It delegates deep log diagnosis to `analyse-app-logs`.
+Canonical task shape:
+
+`Use $scheduled-runtime-health-check to use a background terminal to run <command>.`
+
+Optional suffixes:
+
+- `Before running, update this project to the latest safe code state.`
+- `Run it in this specific time window: <window>.`
+- `After the run completes, explain your findings from the logs.`
+
+This skill is an orchestration layer. It owns the background terminal session, optional code-update step, optional scheduling, bounded runtime, log capture, and optional module-level health summary. It delegates deep log diagnosis to `analyse-app-logs` only when the user asks for findings or the run clearly needs evidence-backed analysis.
 
 ## Core principles
 
 - Prefer one bounded observation window over open-ended monitoring.
+- Use one dedicated background terminal session per requested run so execution and logs stay correlated.
+- Treat code update as optional and only perform it when the user explicitly requests it.
 - Treat startup, steady-state, and shutdown as part of the same investigation.
 - Do not call a module healthy unless there is at least one positive signal for it.
 - Separate scheduler failures, boot failures, runtime failures, and shutdown failures.
@@ -43,44 +54,45 @@ This skill is an orchestration layer. It owns the schedule, bounded runtime, log
 ## Required workflow
 
 1. Define the run contract
-   - Confirm or derive the workspace, start command, stop method, schedule, duration, readiness signal, log locations, and modules to assess.
+   - Confirm or derive the workspace, execution command, optional code-update step, optional schedule, optional duration, readiness signal, log locations, and whether post-run findings are required.
    - Derive commands from trustworthy sources first: `package.json`, `Makefile`, `docker-compose.yml`, `Procfile`, scripts, or project docs.
-   - If no trustworthy start command or stop method can be found, stop and ask only for the missing command rather than guessing.
-2. Choose the scheduling mechanism
-   - Prefer the host's native automation or scheduled-task system when available.
-   - Prefer a single scheduled execution that performs start -> observe -> stop -> analyze so the log window is exact.
-   - If the platform cannot hold a long-running scheduled task, use paired start/stop jobs and record both task identifiers.
+   - If no trustworthy execution command or stop method can be found, stop and ask only for the missing command rather than guessing.
+2. Prepare the background terminal run
+   - Use a dedicated background terminal session for the whole workflow.
+   - Create a dedicated run folder and record timezone, cwd, requested command, terminal session identifier, and any requested start/end boundaries.
+   - Capture stdout and stderr from the beginning of the session so the full run stays auditable.
+3. Optionally update to the latest safe code state
+   - Only do this step when the user explicitly asked to update the project before execution.
+   - Prefer the repository's normal safe update path, such as `git pull --ff-only`, or the project's documented sync command if one exists.
+   - Record the commit before and after the update.
+   - If the worktree is dirty, the branch has no upstream, or the update cannot be done safely, stop and report the exact blocker instead of guessing or forcing a merge.
+4. Choose the execution timing
+   - If the user gave a specific time window, schedule or delay the same background-terminal run to start in that window.
+   - If no time window was requested, run immediately after setup, or after the optional update step if one was requested.
    - If the user requested a future start time and no reliable scheduler is available, fail closed and report the scheduling limitation instead of starting early.
-3. Prepare bounded log capture
-   - Create a dedicated run folder for the window and record absolute start time, intended end time, timezone, cwd, command, and PID or job identifier.
-   - Capture stdout and stderr for the started process, plus any existing app log files that matter for diagnosis.
-   - Keep startup, runtime, and shutdown evidence in the same run record.
-4. Start and verify readiness
-   - Launch the project at the scheduled time.
-   - Wait for a concrete readiness signal such as a health endpoint, listening-port log, worker boot line, or queue-consumer ready message.
-   - If readiness never arrives, stop the run, preserve logs, and analyze the failed startup window.
-5. Observe during the bounded window
-   - Track crashes, restarts, retry storms, timeout bursts, stuck jobs, resource pressure, and repeated warnings.
-   - For each requested module or subsystem, gather at least one positive signal and any degradation signal in the same window.
-   - If the user did not list modules explicitly, infer the major runtime modules from the repository structure and runtime processes.
-6. Stop cleanly at the end of the window
-   - Use the project's normal shutdown path first.
-   - If graceful stop fails, escalate deterministically and record the exact stop sequence and timestamps.
-   - Treat abnormal shutdown behavior as a health signal, not just an operational detail.
-7. Delegate bounded log analysis
+5. Run and capture readiness
+   - Execute the requested command in the same background terminal.
+   - Wait for a concrete readiness signal when the command is expected to stay up, such as a health endpoint, listening-port log, worker boot line, or queue-consumer ready message.
+   - If readiness never arrives, stop the run, preserve logs, and treat it as a failed startup window.
+6. Observe and stop when bounded
+   - If a bounded window or explicit stop time was requested, keep the process running only for that agreed window and then stop it cleanly.
+   - Track crashes, restarts, retry storms, timeout bursts, stuck jobs, resource pressure, and repeated warnings during the run.
+   - Use the project's normal shutdown path first; if graceful stop fails, escalate deterministically and record the exact stop sequence and timestamps.
+7. Explain findings from logs when requested
+   - If the user asked for findings after completion, wait for the run to finish before analyzing the captured logs.
    - Invoke `analyse-app-logs` on only the captured runtime window.
    - Pass the service or module names, environment, timezone, run folder, relevant log files, and the exact start/end boundaries.
    - Reuse its confirmed issues, hypotheses, and monitoring improvements instead of rewriting a separate incident workflow.
-8. Produce the runtime health report
-   - Summarize the schedule that was executed, whether readiness succeeded, how long the project stayed healthy, and how shutdown behaved.
-   - Classify each module as `healthy`, `degraded`, `failed`, or `unknown` with concrete evidence.
-   - Separate already observed issues from potential risks that need more telemetry or a longer run to confirm.
+8. Produce the final report
+   - Always summarize the actual command executed, actual start/end timestamps, execution status, and log locations.
+   - Include the code-update result only when an update step was requested.
+   - When findings were requested, classify each relevant module as `healthy`, `degraded`, `failed`, or `unknown` with concrete evidence and separate observed issues from risks that still need validation.
 
 ## Scheduling rules
 
 - Use the user's locale timezone when configuring scheduled tasks.
 - Name scheduled jobs clearly so the user can recognize start, stop, and analysis ownership.
-- Prefer recurring schedules only when the user explicitly wants repeated health checks; otherwise create a one-off bounded run.
+- Prefer recurring schedules only when the user explicitly wants repeated checks; otherwise create a one-off bounded run.
 - If the host provides agent automations, use them before inventing project-local scheduling files.
 - If native automation is unavailable, prefer the smallest reliable OS-level scheduling method already present on the machine.
 - If the request depends on a future start time and no reliable scheduling method exists, do not silently convert the request into an immediate run.
@@ -99,21 +111,26 @@ Absence of errors alone is not enough for `healthy`.
 Use this structure in responses:
 
 1. Run summary
-   - Workspace, schedule, actual start/end timestamps, duration, readiness result, shutdown result, and log locations.
-2. Module health
-   - One entry per module with status (`healthy` / `degraded` / `failed` / `unknown`) and evidence.
-3. Confirmed issues
-   - Reuse evidence-backed findings from `analyse-app-logs`.
-4. Potential issues and validation needed
-   - Risks that appeared in the run but need more evidence.
-5. Observability gaps
-   - Missing logs, metrics, probes, or correlation IDs that blocked diagnosis.
-6. Automation or scheduler status
-   - Created task identifiers, execution status, and whether future cleanup is needed.
+   - Workspace, command, schedule if any, actual start/end timestamps, duration if bounded, readiness result, shutdown result if applicable, and log locations.
+2. Execution result
+   - Whether the command completed, stayed up for the requested window, or failed early.
+3. Code update result
+   - Include only when an update step was requested. Record the update command, before/after commit, or the exact blocker.
+4. Module health
+   - Include only when findings were requested or health assessment was part of the task. One entry per module with status (`healthy` / `degraded` / `failed` / `unknown`) and evidence.
+5. Confirmed issues
+   - Include only when log analysis was requested. Reuse evidence-backed findings from `analyse-app-logs`.
+6. Potential issues and validation needed
+   - Include only when log analysis was requested. Risks that appeared in the run but need more evidence.
+7. Observability gaps
+   - Include only when log analysis was requested. Missing logs, metrics, probes, or correlation IDs that blocked diagnosis.
+8. Automation or scheduler status
+   - Include only when a future window or scheduler was involved. Record task identifiers, execution status, and whether future cleanup is needed.
 
 ## Guardrails
 
 - Do not let the project continue running past the agreed window unless the user explicitly asks.
+- Do not perform a code-update step unless the user explicitly asked for it.
 - Do not claim steady-state health from startup-only evidence.
 - Keep the run folder and scheduler metadata so the investigation can be reproduced.
 - If current logs are too weak to judge module health, recommend `improve-observability` instead of stretching the evidence.

package/scheduled-runtime-health-check/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Scheduled Runtime Health Check"
-  short_description: "Schedule a bounded project run, then assess module health from captured logs."
-  default_prompt: "Use $scheduled-runtime-health-check to schedule a bounded project run, capture logs from startup through shutdown, classify module health across the requested subsystems, and delegate evidence-based post-run diagnosis to $analyse-app-logs."
+  short_description: "Use a background terminal to run a command in a time window and optionally explain findings from logs."
+  default_prompt: "Use $scheduled-runtime-health-check to use a background terminal to run the requested command immediately or in the requested time window, optionally update the project first only when the user asks for that, capture logs through the run, and, when findings are requested, delegate bounded post-run log diagnosis to $analyse-app-logs."