@jevitate/cli 0.8.0 → 0.10.0

package/skills/jevitate-run-journey/SKILL.md

@@ -28,11 +28,13 @@ artifact; your job is to find the right one and run it with the right params.
 - MCP: `run_journey({ id, params, storageState? })` — same param-schema
   validation, same refusal on an unknown id or params. It NEVER accepts inline
   steps or a raw recording — a published id only.
-- Read the JSON envelope's `outcome` field. `"ok"` and `"healed"` (a run that
-  recovered via self-heal) are both successes (exit 0); `"quarantined"` (exit 1)
-  and any other value, including a secret-handback pause, mean it did not
-  complete — report that honestly, with the step it stopped at. Exit 64 is a
-  refusal before anything ran (unknown id, bad params, a step off the allowlist).
+- Read the JSON envelope's `outcome` field (MCP: also `exitCode`). Only `"ok"`
+  (exit 0) is a pass. `"healed-pending-review"` (exit 5) is NOT a pass: a
+  self-heal retargeted steps and proposed a Journey revision a person must
+  accept. `"heal-exhausted"` and `"quarantined"` (exit 1) and any other value,
+  including a secret-handback pause, mean it did not complete — report that
+  honestly, with the step it stopped at. Exit 64 is a refusal before anything
+  ran (unknown id, bad params, a step off the allowlist).
 
 ## Where it runs (`--env`) and what it records
 
@@ -70,6 +72,24 @@ artifact; your job is to find the right one and run it with the right params.
   preserves the plain, unhealed behavior. `hybrid`/`full` need an AI gateway
   (`--real` after `jevitate ai setup`, or `--fake-ai` for a pipeline smoke);
   requesting a heal mode without one fails closed rather than running unhealed.
+- A heal mode also needs a change context, or it is refused (exit 64):
+  `--changes <git range>` (e.g. `HEAD~1..HEAD`, read-only) and/or one or more
+  `--change-note "renamed \"Create New\" to \"Create\""`. MCP: `changes`,
+  `changeNote`. Only a break that change explains is retargeted, one step for
+  one step; assertions, waits and request checks are never changed. A break the
+  change does not explain stays `quarantined` (a likely regression).
+- Budgets bound the heal: `--heal-max-attempts` (2) / `--heal-max-model-calls`
+  (6) / `--heal-max-ms` per broken step; `--heal-max-run-attempts` (4) /
+  `--heal-max-run-ms` per run. Exhausting them ends `heal-exhausted` (exit 1)
+  with every attempt in the result.
+- A healed run ends `healed-pending-review` (exit 5) and writes a proposal
+  (`result.proposal`: id, path, steps, `reviewCommand`, `acceptCommand`); the
+  stored Journey is untouched. Next: `jevitate journey review <id>` (MCP
+  `review_journey`), then a person accepts with
+  `jevitate journey promote <id> --proposal <pid>` or rejects with
+  `--reject-proposal <pid> --reason "<text>"`. Do not accept a proposal on the
+  user's behalf unless they asked you to. Show the user the changed steps and
+  the evidence it cites.
 - A write/irreversible step NEVER auto-heals in any mode — that floor is
   enforced by the runtime, not something you can override from a flag.
 
@@ -92,6 +112,17 @@ artifact; your job is to find the right one and run it with the right params.
   proof, change since the last approval, and the content hash. Pass that hash
   as `--reviewed-hash` (MCP `reviewedHash`) so the approval is refused
   (`E_JOURNEY_REVIEW_STALE`) if the Journey changed after they read it.
+- A new Journey, or one whose content changed beyond step ids, must follow the
+  anchor rules to promote (lowercase anchor names, anchors carrying their
+  step's `stepId`, a job-linked Journey naming at least one anchor, valid
+  `serves`/`jobStep` references); otherwise promote is refused with
+  `E_JOURNEY_ANCHOR_RULES` and the fix for each problem. The sheet and
+  `journey lint` show the same problems as warnings first.
+- `jevitate journey review --stale --json` (MCP `review_journey` with
+  `stale: true`) lists every promoted Journey whose approval is stale;
+  `stepIdOnly: true` marks one whose only change is minted step ids (after
+  `jevitate journey migrate --step-ids`, which the operator runs and
+  commits). Re-approving those is still the person's act.
 - `jevitate journey promote <id>` promotes a local Journey — a person's
   approval, never automatic. It needs an interactive terminal: after the
   sheet, the person types the Journey id (or the first 8 characters of its

package/skills/jevitate-test-campaign/SKILL.md

@@ -44,6 +44,14 @@ never the click path; independent `--success` checks (page or network state); pr
 whether it mutates state; and a run order (jobs that create data run before jobs that use it).
 A job you can't write a checkable `--success` for is too vague. Split it or narrow it.
 
+Optionally give a job its steps and desired outcomes (`steps`, `desiredOutcomes` with a `metric`
+measured between anchors or the reserved `"job_start"` / `"job_end"`, a `target`, `guardrail: true`
+for what must never get worse; docs/catalog.md). `jevitate job draft-outcomes <id> --real --json`
+(MCP `draft_job_outcomes`) drafts 1-3 outcomes marked `provenance: ai_draft` for the human to
+review; it never approves, and an approved job becomes stale. On each job-linked Journey, mark
+where the job's steps start and end with anchors (`jobStep`, `boundary`), so its metrics are
+measurable; `catalog status` lists the reference problems (`refIssues`).
+
 ## 3. Discovery: one goal run per job
 
 For each job, as the right persona, with no scripted path:
@@ -167,6 +175,11 @@ probability ≥ its `threshold` (Jev only advises). Then `jevitate catalog statu
 `fixed` by verify-fix (with a ledger entry or regression); the final round ran on the release
 build; and no `inconclusive` run was counted as a pass. Anything short of that, report it as open.
 
+To share the vetted catalog, `jevitate catalog export --format journeeze-bundle --out <dir>
+[--check <check.json>] --json` (MCP `export_catalog_bundle`) writes a Journeeze catalog bundle, and
+`jevitate publish journeeze --json` (MCP `publish_to_journeeze`) uploads it once a person has run
+`jevitate connect journeeze` (or CI sets `JOURNEEZE_UPLOAD_KEY`). Neither approves anything.
+
 ## Templates
 
 Job spec (one per job, `.jevitate/jobs.json`; the old `.jevitate/campaign/jobs.json` is still