@amistio/cli 0.1.50 → 0.1.51

package/README.md

@@ -29,7 +29,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, implementation-verification, and prompt-batch work until updated. Normal runner polling also refreshes self-maintenance health in the Evaluate panel with bounded counts, trend, and safe record IDs for operational drift. The same polling path can run a throttled safe Project Brain consolidation pass that archives exact duplicate untouched generated review docs and queues semantic brain consolidation only when a compatible runner and active repository link exist. It does not upload source, full document bodies, secrets, commands, or local paths, and it does not delete brain records, repo files, approved/synced docs, or user-edited docs. With repository autopilot enabled and an online compatible runner, self-maintenance may requeue only backend-proven safe failed or blocked work; repeated blockers and unsafe rows stay held for review.
+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, implementation-verification, and prompt-batch work until updated. Normal runner polling also refreshes self-maintenance health in the Evaluate panel with bounded counts, trend, and safe record IDs for operational drift. The same polling path can run a throttled safe Project Brain consolidation pass that archives exact duplicate untouched generated review docs and queues semantic brain consolidation only when a compatible runner and active repository link exist. It also runs blocker elimination for failed/blocked work: autopilot-disabled projects get reviewable deduped unblock work, autopilot-enabled projects may requeue backend-proven safe rows or approve low-risk verification/handoff/stale-base repairs under policy, and true manual exceptions name the external input needed to resume. It does not upload source, full document bodies, secrets, commands, or local paths, and it does not delete brain records, repo files, approved/synced docs, or user-edited docs.
 
 Prompt batches are first-class `promptBatch` work items for many approved prompts that should reach the worker together. The CLI claims one manifest, executes child prompts sequentially, reports per-child status back to Amistio, and stops according to the batch policy. This preserves auditability while avoiding repeated one-prompt handoffs; it is not shell-script batching, terminal loops, or hidden chat concatenation.
 

package/dist/index.js

@@ -7900,7 +7900,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. This includes Ready prompts for repeatable archived-brain or empty-approved-brain cleanup utilities after a one-time cleanup archived historical records. Do not archive them just because the initial cleanup succeeded; use keepActive unless controlling evidence proves the reusable work was completed, superseded, or rejected.",
+    "- 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. This includes Ready prompts for repeatable archived-brain or empty-approved-brain cleanup utilities after a one-time cleanup archived historical records, and active blocker-elimination or work-recovery loops after a previous blocked-work cleanup, handoff recovery, or one-time recovery pass completed. Do not archive them just because the initial cleanup or recovery pass succeeded; use keepActive unless controlling evidence proves the reusable work or recovery loop 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.",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@amistio/cli",
-  "version": "0.1.50",
+  "version": "0.1.51",
   "type": "module",
   "repository": {
     "type": "git",