@amistio/cli 0.1.33 → 0.1.34

package/README.md

@@ -15,7 +15,7 @@ Runner lifecycle controls in the web app, such as update, restart, and remove, a
 
 Runner Update installs the official `@amistio/cli` package and then refreshes the runner runtime. Background runners attempt a replacement restart so the next heartbeat reports the new CLI version. If replacement restart metadata is missing or restart fails after a successful install, the old runner still stops and reports manual restart guidance instead of continuing to heartbeat the stale runtime. Foreground `amistio run --watch` sessions stop after a successful install with restart guidance; start the command again to load the updated package.
 
-Current runners advertise the work kinds they can claim. Older runners that do not send this capability can continue legacy brain generation, implementation, and plan revision work, but they will skip source-aware assistant, impact-preview, semantic brain consolidation, project-context refresh, issue-diagnosis, app-evaluation, security-posture, Test-quality, implementation-Test-gate, and implementation-verification work until updated.
+Current runners advertise the work kinds they can claim. Older runners that do not send this capability can continue legacy brain generation, implementation, and plan revision work, but they will skip source-aware assistant, impact-preview, semantic brain consolidation, project-context refresh, issue-diagnosis, app-evaluation, security-posture, Test-quality, implementation-Test-gate, and implementation-verification work until updated. Normal runner polling also refreshes review-only self-maintenance health in the Evaluate panel with bounded counts, trend, and safe record IDs for operational drift; it does not upload source, full document bodies, secrets, commands, local paths, or mutate cleanup targets.
 
 Tool session reuse is bounded. One-shot tool sessions close after successful completion, failed runs are blocked, active sessions are treated as already in use, and reusable sessions idle for more than six hours are closed before the next claim selects context. This keeps follow-up work from inheriting stale local AI context while preserving recent reusable sessions for related work.
 

package/dist/index.js

@@ -6188,6 +6188,7 @@ function createAppEvaluationScanPrompt(workItem, context) {
     "- Treat intentionally in-progress feature tracks as still-active work when their controlling plan/feature has unchecked requirements or explicit follow-up gaps. For example, a completed first implementation prompt does not make the broader feature stale if PLAN/FEAT evidence says remaining lifecycle work is still open; return proposedLifecycleAction keepActive with evidence instead of cleanup.",
     "- Treat prompt frontmatter status Ready as an active execution backlog state by default, not as stale review debt. Only flag a Ready prompt for metadata correction when its controlling plan, feature, prompt index, or verification evidence unambiguously proves the prompt has already completed or been superseded.",
     "- Treat implemented umbrella plans that explicitly label unchecked checklist items as deferred follow-ups, future candidates, roadmap backlog, or split-out hardening phases as valid deferred backlog. Do not mark the umbrella incomplete or stale solely because those deferred items remain unchecked; use keepActive or no cleanup, and recommend a fresh focused plan only when a concrete deferred slice has current evidence and approval.",
+    "- Treat reusable hygiene tooling and recurring health-loop prompts/plans as active operational backlog when the one-time cleanup or prevention pass has executed but the repeatable utility or recurring workflow remains explicitly Ready, Proposed, or unchecked. Do not archive them just because the initial cleanup succeeded; use keepActive unless controlling evidence proves the reusable work was completed, superseded, or rejected.",
     "- When lifecycle metadata disagrees across indexes, frontmatter, feature specs, ADRs, and implementation evidence, cite the conflict and propose a metadata correction or verification step instead of archival/removal.",
     "- Check missing memory or workflow updates when repeated lessons or operational rules are visible.",
     "- Check release readiness, UX, accessibility, performance, reliability, and security-posture follow-through at a summary level.",