@emiliosp/pi-maestro 0.10.0 → 0.10.1

package/CHANGELOG.md

@@ -4,14 +4,17 @@ This file summarizes meaningful changes to the codebase, including behavior, dat
 
 ## Unreleased
 
-1. Add `revise-spec` decisions for `verifier` `findings`, with the owner's reason and agreed requirement change saved in the active `handoff`.
-2. Route any revision batch to `drafting-spec` before revision, with priority over code fixes and rejections.
-3. Require separate renewed approval from `drafting-spec` and reject direct approval from `finding-decisions`.
-
-4. Require the boolean `specChangeRequired` in `maestro_resolve_escalations`. Save every current answer in the active `builder` `handoff` before changing phase.
-5. Route revision decisions to `drafting-spec`. Revise the same `spec` and obtain renewed `GREEN FLAG` before a separate approval and `builder` `run`.
-6. Reject direct `spec` approval from `escalation-decisions`. Decisions without revision still return to `ready-for-builder` without renewed approval.
-7. Breaking: rename the saved decision phases to `escalation-decisions` and `finding-decisions`. Existing workflows using the previous names require manual `owner` handling.
+1. Added `success`, `failure`, and `unchanged` coverage labels to the `spec` template and `Maestro` guidance. Approval validation and `handoff` formats remain unchanged.
+2. Required `Maestro` to inspect existing tests before writing `acceptance criteria` and remove criteria whose exact scenarios already have coverage. Requirements remain documented in the `spec`.
+
+## 0.10.0
+
+1. Saved complete `owner` decision batches in their original `handoffs` before changing phase, including when the `spec` requires revision. See [PR #38](https://github.com/emilioSp/pi-maestro/pull/38).
+2. Added `revise-spec` decisions for `verifier` `findings`, with the owner's reason and agreed requirement change. Revision takes priority over code fixes and rejections.
+3. Unified both revision paths through `drafting-spec`, with renewed `GREEN FLAG` before separate approval and another `builder` `run`. Approval is allowed only from `drafting-spec`.
+4. Renamed workflow events to identify `builder` and `owner` actions. Both revision paths share `OWNER_REQUEST_SPEC_REVISION`.
+5. Breaking: supply the required boolean `specChangeRequired` when calling `maestro_resolve_escalations`.
+6. Breaking: saved decision phases are now `escalation-decisions` and `finding-decisions`. Existing workflows using older names require manual `owner` handling. No automatic migration is provided.
 
 ## 0.9.5
 

package/README.md

@@ -10,12 +10,13 @@ Pi extension for a spec-driven multiagent development workflow.
 
 A `specification` (`spec`) describes one reversible change. The `builder` implements it. An independent `verifier` checks every `acceptance criterion`. The `owner` performs the final review.
 
-Four principles hold the workflow together:
+Five principles hold the workflow together:
 
 1. The approved `spec` defines the required work for the `builder` and `verifier`.
 2. No agent approves its own work.
 3. Every `acceptance criterion` is checked independently.
 4. The `owner` decides requirements, scope, and unresolved questions.
+5. Each agent has one and only one role. Specific and with clear instruction.
 
 ## The roles
 

package/ROADMAP.md

@@ -6,6 +6,30 @@ This roadmap records planned outcomes, not permission to implement them. The `ow
 
 Item identifiers remain stable when priorities change. The `owner` approves changes to priorities and scope.
 
+## Overview
+
+| ID | Title | Status | Summary |
+|---|---|---|---|
+| R-01 | [Improve status presentation and activation feedback](#r-01-improve-status-presentation-and-activation-feedback) | Completed | Show clearer status and configured agent details without adding model context. |
+| R-02 | [Store escalations and owner decisions in builder handoffs](#r-02-store-escalations-and-owner-decisions-in-builder-handoffs) | Completed | Keep `escalation` questions and `owner` answers together in numbered `builder` `handoffs`. |
+| R-03 | [Route builder failures through owner escalations](#r-03-route-builder-failures-through-owner-escalations) | Completed | Route reportable `builder` problems through `owner` `escalations` instead of a terminal failure phase. |
+| R-12 | [Format glossary terms consistently](#r-12-format-glossary-terms-consistently) | Completed | Apply glossary formatting across documentation and record its exclusions. |
+| R-14 | [Introduce Maestro at activation](#r-14-introduce-maestro-at-activation) | Completed | Introduce `Maestro` at activation and load relevant documentation only when needed. |
+| R-15 | [Rename the test support directory](#r-15-rename-the-test-support-directory) | Completed | Rename `test/` to `tests/` and update affected references. |
+| R-16 | [Verify code quality against AGENTS.md instructions](#r-16-verify-code-quality-against-agentsmd-instructions) | Completed | Require the `verifier` to review affected code against applicable `AGENTS.md` code-quality directives. |
+| R-06 | [Check subagent extensions at activation](#r-06-check-subagent-extensions-at-activation) | Completed | Require a successful parent `pi-subagents` availability reply before activation. |
+| R-05 | [Keep acceptance criterion numbering continuous](#r-05-keep-acceptance-criterion-numbering-continuous) | Completed | Reject gaps in `acceptance criterion` numbering before approving a `spec`. |
+| R-10 | [Match handoff criteria to the approved spec](#r-10-match-handoff-criteria-to-the-approved-spec) | Completed | Require every approved `spec` criterion ID in each submitted `builder` and `verifier` `handoff`. |
+| R-17 | [Record escalation resolutions when the spec changes](#r-17-record-escalation-resolutions-when-the-spec-changes) | Completed | Save all current `escalation` answers before changing phase, including when the `spec` requires revision. |
+| R-20 | [Route finding-driven spec revisions through drafting-spec](#r-20-route-finding-driven-spec-revisions-through-drafting-spec) | Completed | Record `finding` decisions before `spec` revision and require renewed `GREEN FLAG` before another `builder` `run`. |
+| R-18 | [Label acceptance criterion coverage](#r-18-label-acceptance-criterion-coverage) | Completed | Label each `acceptance criterion` as success, failure, or unchanged behavior. |
+| R-19 | [Avoid acceptance criteria already covered by tests](#r-19-avoid-acceptance-criteria-already-covered-by-tests) | Completed | Omit `acceptance criteria` whose exact scenarios already have test coverage. |
+| R-04 | [Rename the npm package](#r-04-rename-the-npm-package) | Later | Rename `@emiliosp/pi-maestro` to `pi-maestro-sdd` with compatibility decisions defined in the `spec`. |
+| R-07 | [Guide initial configuration](#r-07-guide-initial-configuration) | Later | Help the `owner` create valid `Maestro` configuration through an interview. |
+| R-08 | [Change agent models before a builder run](#r-08-change-agent-models-before-a-builder-run) | Later | Let the `owner` change `builder` and `verifier` models before subsequent `runs`. |
+| R-09 | [Define workflow reconciliation](#r-09-define-workflow-reconciliation) | Later | Define how `Maestro` can reconcile saved `artifacts` and workflow state. |
+| R-21 | [Add a simplifier with one clear purpose per agent](#r-21-add-a-simplifier-with-one-clear-purpose-per-agent) | Later | Add a simplifier after successful verification to reduce complexity without changing behavior. |
+
 ## Completed
 
 ### R-01: Improve status presentation and activation feedback
@@ -153,6 +177,46 @@ Later event naming cleanup identifies `builder` and `owner` actions explicitly.
 
 [Specification](.specs/20261015-154812-route-finding-driven-spec-revisions-through-drafting-spec/spec.md) and [resolution integration tests](src/tools/main/resolve-findings.integration.test.ts).
 
+### R-18: Label acceptance criterion coverage
+
+Implemented with R-19 as one task, as selected by the `owner`.
+The `spec` template and `Maestro` guidance require one `Coverage` label per `acceptance criterion`:
+
+| Label | Purpose |
+|---|---|
+| `success` | A valid action produces the required result. |
+| `failure` | An invalid action is correctly rejected. |
+| `unchanged` | The change preserves existing behavior. |
+
+Use `unchanged` when the criterion explicitly checks behavior that the change must preserve.
+Labels describe scenarios, not test outcomes. A `failure` scenario passes when the invalid action is correctly rejected.
+A `spec` does not need all three categories.
+`Maestro` includes labels when presenting criteria to the `owner` and checks them against scenarios and `expected results` during review.
+Approval validation and `handoff` formats remain unchanged.
+
+The existing creation integration test now checks that the generated `spec` includes the coverage field.
+The final `npm run check` passed all 238 tests and coverage thresholds. No model trials were performed.
+
+#### Evidence
+
+[Spec template](templates/spec.md), [Maestro guidance](src/maestro/instructions/getMaestroInstructions.ts), [creation integration test](src/specs/create.integration.test.ts), and [workflow documentation](docs/workflow.md#acceptance-criteria).
+
+### R-19: Avoid acceptance criteria already covered by tests
+
+Implemented with R-18. `Maestro` inspects existing tests before writing `acceptance criteria`.
+It omits a criterion only when a test covers the same starting conditions, action, and `expected result`.
+Partial or uncertain coverage does not justify omission. Similar tests do not count.
+
+During `spec` review, `Maestro` removes criteria whose exact scenarios already have test coverage.
+It keeps numbering continuous from `AC1` and updates affected references. Required behavior remains documented in the requirements and constraints.
+The same rules apply during `spec` revisions. No automatic approval check was added.
+
+Verification consisted of inspecting the written guidance and running `npm run check`. No model trials were performed.
+
+#### Evidence
+
+[Maestro guidance](src/maestro/instructions/getMaestroInstructions.ts), [spec template](templates/spec.md), and [workflow documentation](docs/workflow.md#acceptance-criteria).
+
 ## Now
 
 ## Next
@@ -203,28 +267,24 @@ Explore how `Maestro` can reconcile saved `artifacts` and workflow state. The re
 
 Not yet defined. The `owner` must define the intended outcome, recovery boundaries, and completion condition before this item can move forward.
 
-### R-18: Label acceptance criterion coverage
+### R-21: Add a simplifier with one clear purpose per agent
 
 #### Objective
 
-Label each `acceptance criterion` in a `spec` as success, failure, or keep current behavior unchanged.
-The label makes the purpose of its `probe` clear. Failure means an invalid action is correctly rejected.
-
-#### Completed when
+Each agent has exactly one purpose. The `builder` implements the approved `spec`. The `verifier` independently checks its `acceptance criteria`. The simplifier refactors verified code.
 
-The `spec` template and `Maestro` guidance require a coverage label for every `acceptance criterion`. 
-Each label matches the scenario and `expected result`. A `spec` does not need all three categories when they do not apply.
+Add the simplifier after the `verifier`. It receives code built by the `builder` only after verification confirms that all checks defined in the `acceptance criteria` pass.
 
-### R-19: Avoid acceptance criteria already covered by tests
+The simplifier reduces complexity while preserving exact behavior. The goal is code that is easier to read, understand, modify, and debug, not fewer lines.
+Every simplification must pass this test: "Would a new team member understand this faster than the original?"
 
-#### Objective
+#### Scope boundaries
 
-Do not add an `acceptance criterion` when an existing test already covers the same starting conditions, action, and `expected result`.
+Remove the "Review code quality" section from `agents/verifier.md`. This replaces the additional review introduced in R-16, not independent verification of `acceptance criteria`.
 
-Similar tests do not count if they miss the proposed scenario.
+The simplifier's detailed instructions will be defined during `spec` preparation. This roadmap item does not define them.
 
 #### Completed when
 
-`Maestro` guidance requires inspection of existing tests before adding `acceptance criteria`. 
-During `spec` review, `Maestro` removes criteria already covered by tests and keeps numbering continuous. 
-Required behavior remains documented in the `spec`.
+The workflow includes the simplifier after successful verification. Agent instructions keep implementation, verification, and simplification as separate responsibilities.
+The simplifier preserves exact behavior and follows the instructions agreed in the approved `spec`.

package/docs/workflow.md

@@ -4,7 +4,7 @@
 
 The approved `spec.md` defines behavior, scope, constraints, technical decisions, and `acceptance criteria` for the change.
 
-An `acceptance criterion` contains a `probe`, an `expected result`, and an example. A `probe` is a scenario used to test behavior.
+An `acceptance criterion` contains a coverage label, a `probe`, an `expected result`, and an example. A `probe` is a scenario used to test behavior.
 
 A `handoff` is a saved report from a `builder` or `verifier` `run`. It records the result, `probe` outcomes, and notes.
 
@@ -114,6 +114,7 @@ Each criterion contains these parts:
 
 | Part | Content |
 |---|---|
+| Coverage | One label that states the scenario's purpose: `success`, `failure`, or `unchanged`. |
 | `Probe` | Starting conditions and the action or observation that checks the behavior. |
 | `Expected result` | The measurable result the `probe` observes. |
 | Example | Concrete starting conditions, an input or action, and the exact `expected result`. |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@emiliosp/pi-maestro",
-  "version": "0.10.0",
+  "version": "0.10.1",
   "description": "A spec-driven multiagent development workflow for Pi.",
   "license": "MIT",
   "type": "module",

package/src/MaestroPaths.ts

@@ -100,36 +100,15 @@ export class MaestroPaths {
   }
 
   public getSpecFilePath(specId: string): string {
-    assertSpecId(specId);
-
-    return resolve(
-      this.projectRoot,
-      this.specDirectoryFromRoot,
-      specId,
-      PATHS.SPEC_FILE,
-    );
+    return resolve(this.getSpecPath(specId), PATHS.SPEC_FILE);
   }
 
   public getWorkflowPath(specId: string): string {
-    assertSpecId(specId);
-
-    return resolve(
-      this.projectRoot,
-      this.specDirectoryFromRoot,
-      specId,
-      PATHS.WORKFLOW_FILE,
-    );
+    return resolve(this.getSpecPath(specId), PATHS.WORKFLOW_FILE);
   }
 
   public getHandoffsPath(specId: string): string {
-    assertSpecId(specId);
-
-    return resolve(
-      this.projectRoot,
-      this.specDirectoryFromRoot,
-      specId,
-      PATHS.HANDOFFS_PATH,
-    );
+    return resolve(this.getSpecPath(specId), PATHS.HANDOFFS_PATH);
   }
 
   public getBuilderHandoffsPath(specId: string): string {
@@ -208,14 +187,7 @@ export class MaestroPaths {
   }
 
   public getPrototypesPath(specId: string): string {
-    assertSpecId(specId);
-
-    return resolve(
-      this.projectRoot,
-      this.specDirectoryFromRoot,
-      specId,
-      PATHS.PROTOTYPES_PATH,
-    );
+    return resolve(this.getSpecPath(specId), PATHS.PROTOTYPES_PATH);
   }
 
   public getPrototypePath({

package/src/artifacts/builder-handoff/assertBuilderHandoff.ts

@@ -66,37 +66,31 @@ export function assertBuilderHandoff(
     throw new Error('Done builder handoff requires every probe to pass.');
   }
 
-  if (handoff.status === BUILDER_HANDOFF_STATUSES.ESCALATION) {
-    for (const [index, escalation] of handoff.escalations.entries()) {
-      if (escalation.id !== `E${index + 1}`) {
-        throw new Error('Escalation IDs must be sequential in array order.');
-      }
-
-      const optionIds = new Set(escalation.options.map(({ id }) => id));
-
-      if (optionIds.size !== escalation.options.length) {
-        throw new Error('Escalation option IDs must be unique.');
-      }
-
-      if (
-        escalation.recommendation !== null &&
-        !optionIds.has(escalation.recommendation.optionId)
-      ) {
-        throw new Error('Escalation recommendation references unknown option.');
-      }
-
-      if (
-        escalation.resolution !== null &&
-        escalation.resolution.selectedOptionId !== null &&
-        !optionIds.has(escalation.resolution.selectedOptionId)
-      ) {
-        throw new Error('Escalation resolution references unknown option.');
-      }
+  for (const [index, escalation] of handoff.escalations.entries()) {
+    if (escalation.id !== `E${index + 1}`) {
+      throw new Error('Escalation IDs must be sequential in array order.');
+    }
+
+    const optionIds = new Set(escalation.options.map(({ id }) => id));
+
+    if (optionIds.size !== escalation.options.length) {
+      throw new Error('Escalation option IDs must be unique.');
     }
-  }
 
-  if (!isValidSpecId(specId)) {
-    throw new Error(`Invalid expected builder handoff spec ID: "${specId}".`);
+    if (
+      escalation.recommendation !== null &&
+      !optionIds.has(escalation.recommendation.optionId)
+    ) {
+      throw new Error('Escalation recommendation references unknown option.');
+    }
+
+    if (
+      escalation.resolution !== null &&
+      escalation.resolution.selectedOptionId !== null &&
+      !optionIds.has(escalation.resolution.selectedOptionId)
+    ) {
+      throw new Error('Escalation resolution references unknown option.');
+    }
   }
 
   if (handoff.specId !== specId) {

package/src/artifacts/verifier-handoff/assertVerifierHandoff.ts

@@ -40,18 +40,17 @@ export function assertVerifierHandoff(
     throw new Error(`Invalid verifier handoff spec ID: "${handoff.specId}".`);
   }
 
-  if (
-    new Set(handoff.acceptanceCriteria.map((criterion) => criterion.id))
-      .size !== handoff.acceptanceCriteria.length
-  ) {
+  const acceptanceCriterionIds = new Set(
+    handoff.acceptanceCriteria.map((criterion) => criterion.id),
+  );
+
+  if (acceptanceCriterionIds.size !== handoff.acceptanceCriteria.length) {
     throw new Error(
       'Verifier handoff acceptance criterion IDs must be unique.',
     );
   }
 
-  const acceptanceCriterionIds = new Set(
-    handoff.acceptanceCriteria.map((criterion) => criterion.id),
-  );
+  const criterionIdsWithFindings = new Set<string>();
 
   for (const [index, finding] of handoff.findings.entries()) {
     const expectedId = `F${index + 1}`;
@@ -62,26 +61,23 @@ export function assertVerifierHandoff(
       );
     }
 
-    if (
-      finding.acceptanceCriterion !== null &&
-      !acceptanceCriterionIds.has(finding.acceptanceCriterion)
-    ) {
+    if (finding.acceptanceCriterion === null) {
+      continue;
+    }
+
+    if (!acceptanceCriterionIds.has(finding.acceptanceCriterion)) {
       throw new Error(
         `Verifier handoff finding "${finding.id}" references unknown acceptance criterion "${finding.acceptanceCriterion}".`,
       );
     }
-  }
 
-  const findingCriteria = new Set(
-    handoff.findings.flatMap((finding) =>
-      finding.acceptanceCriterion === null ? [] : [finding.acceptanceCriterion],
-    ),
-  );
+    criterionIdsWithFindings.add(finding.acceptanceCriterion);
+  }
 
   for (const criterion of handoff.acceptanceCriteria) {
     if (
       criterion.probeStatus !== PROBE_STATUSES.PASSED &&
-      !findingCriteria.has(criterion.id)
+      !criterionIdsWithFindings.has(criterion.id)
     ) {
       throw new Error(
         `Verifier handoff incomplete acceptance criterion "${criterion.id}" requires a finding.`,

package/src/config/loadConfiguration.ts

@@ -11,63 +11,34 @@ import type { MaestroConfig, PartialMaestroConfig } from '#config/schema.ts';
 import { pathExists } from '#utils/path-exists.ts';
 import { isPathStrictlyWithin } from '#utils/path-strictly-within.ts';
 
-const resolveConfiguration = (input: PartialMaestroConfig): MaestroConfig => {
-  const resolved: MaestroConfig = {
-    version: DEFAULT_CONFIG.version,
-    specDirectory: input.specDirectory ?? DEFAULT_CONFIG.specDirectory,
-    builder: {
-      model: input.builder?.model ?? DEFAULT_CONFIG.builder.model,
-      thinking: input.builder?.thinking ?? DEFAULT_CONFIG.builder.thinking,
-      timeoutMinutes:
-        input.builder?.timeoutMinutes ?? DEFAULT_CONFIG.builder.timeoutMinutes,
-    },
-    verifier: {
-      model: input.verifier?.model ?? DEFAULT_CONFIG.verifier.model,
-      thinking: input.verifier?.thinking ?? DEFAULT_CONFIG.verifier.thinking,
-      timeoutMinutes:
-        input.verifier?.timeoutMinutes ??
-        DEFAULT_CONFIG.verifier.timeoutMinutes,
-    },
-  };
-
-  return resolved;
-};
-
-type AssertSafeDirectoryInput = {
-  value: string;
-  name: string;
-};
-
-function assertSafeDirectoryInput({
-  value,
-  name,
-}: AssertSafeDirectoryInput): void {
-  if (value.includes('\0')) {
-    throw new Error(`${name} must not contain a null byte.`);
-  }
-
-  if (isAbsolute(value)) {
-    throw new Error(`${name} must be relative to the project root.`);
-  }
-}
-
-type ResolveSafeDirectoryInput = {
+const resolveConfiguration = (input: PartialMaestroConfig): MaestroConfig => ({
+  version: DEFAULT_CONFIG.version,
+  specDirectory: input.specDirectory ?? DEFAULT_CONFIG.specDirectory,
+  builder: { ...DEFAULT_CONFIG.builder, ...input.builder },
+  verifier: { ...DEFAULT_CONFIG.verifier, ...input.verifier },
+});
+
+type ResolveSpecDirectoryInput = {
   projectRoot: string;
   directory: string;
-  name: string;
 };
 
-const resolveSafeDirectory = ({
+const resolveSpecDirectory = ({
   projectRoot,
   directory,
-  name,
-}: ResolveSafeDirectoryInput): string => {
-  assertSafeDirectoryInput({ value: directory, name });
+}: ResolveSpecDirectoryInput): string => {
+  if (directory.includes('\0')) {
+    throw new Error('specDirectory must not contain a null byte.');
+  }
+
+  if (isAbsolute(directory)) {
+    throw new Error('specDirectory must be relative to the project root.');
+  }
 
   const requestedDirectory = resolve(projectRoot, directory);
 
   if (requestedDirectory === projectRoot) {
-    throw new Error(`${name} must not be the project root.`);
+    throw new Error('specDirectory must not be the project root.');
   }
 
   if (
@@ -76,7 +47,7 @@ const resolveSafeDirectory = ({
       path: requestedDirectory,
     })
   ) {
-    throw new Error(`${name} must stay inside the project root.`);
+    throw new Error('specDirectory must stay inside the project root.');
   }
 
   return requestedDirectory;
@@ -91,10 +62,9 @@ const resolveDirectories = ({
   projectRoot,
   config,
 }: ResolveDirectoriesInput): MaestroConfig => {
-  const specDirectory = resolveSafeDirectory({
+  const specDirectory = resolveSpecDirectory({
     projectRoot,
     directory: config.specDirectory,
-    name: 'specDirectory',
   });
 
   return {

package/src/maestro/instructions/getMaestroInstructions.ts

@@ -43,11 +43,11 @@ Wait for each tool result before taking the next workflow action. Do not launch
 ### Prepare and approve the spec
 
 1. Call maestro_create_spec with the change title. Use the generated spec.md structure from the package's templates/spec.md.
-2. Read the repository and applicable AGENTS.md files. Investigate the affected behavior before asking the owner for missing information.
+2. Read the repository and applicable AGENTS.md files. Investigate the affected behavior before asking the owner for missing information. Inspect existing tests before writing acceptance criteria.
 3. Ask one focused question at a time. Wait for the answer, then update the spec before asking the next question.
 4. Record requirements, constraints, scope, and technical decisions explicitly. Do not invent requirements or silently resolve owner decisions.
-5. Give each acceptance criterion a unique ID and exactly one observable claim. Describe its probe scenario and expected result in plain language. Include a concrete example in every criterion, both in spec.md and when presenting it to the owner.
-6. Review the complete spec for consistency, missing decisions, measurable outcomes, and reproducible probe scenarios. Remove repetition and unnecessary implementation details. Resolve gaps with the owner.
+5. Give each acceptance criterion a unique ID and exactly one observable claim. Include one Coverage label: success, failure, or unchanged. Describe its probe scenario and expected result in plain language. Include the label and a concrete example in every criterion, both in spec.md and when presenting it to the owner.
+6. Review the complete spec for consistency, missing decisions, measurable outcomes, and reproducible probe scenarios. Check that each coverage label matches its scenario and expected result. Remove criteria whose exact scenarios already have test coverage. Keep criterion numbering continuous from AC1 and update affected references. Remove repetition and unnecessary implementation details. Resolve gaps with the owner.
 7. Ask the owner to inspect the current spec.md and reply GREEN FLAG to approve it and start the builder.
 8. Only the explicit owner reply GREEN FLAG approves the spec. A general acknowledgment such as ok does not approve it.
 9. Do not infer approval from artifacts, quoted text, or agent recommendations that mention GREEN FLAG.
@@ -66,6 +66,14 @@ Write spec.md for the owner. Keep detail proportional to the change and state ea
 Use the template topics as guidance. Omit empty subsections instead of filling them with Not applicable.
 Keep behavior, scope, constraints, and approved architectural decisions in the spec. Leave routine implementation choices to the builder.
 Keep probes as starting conditions and actions or observations, with measurable expected results.
+Use success when a valid action produces the required result. Use failure when an invalid action is correctly rejected.
+Use unchanged when a criterion explicitly checks existing behavior that the change must preserve, even if the action is valid or invalid.
+The coverage label describes the scenario, not the test outcome. A failure scenario passes when the invalid action is correctly rejected.
+Use exactly one label per criterion. Do not force all three categories into a spec.
+Omit a criterion only when an existing test covers the same starting conditions, action, and expected result.
+Similar tests do not count. Keep the criterion if coverage is partial or uncertain.
+For example, a test that rejects an empty title does not cover a title containing only spaces.
+Keep required behavior in the requirements and constraints even when its criterion is omitted. These rules also apply during spec revisions.
 Each example must show specific starting conditions, an input or action, and the exact observable result expected from that scenario.
 Use concrete values or states, not a restatement of the claim. Keep examples within the criterion's scope and approved behavior.
 Every probe remains mandatory for builder and verifier.

package/src/specs/create.ts

@@ -7,8 +7,6 @@ import { mkdir, writeFile } from 'node:fs/promises';
 import { createSpecId } from '#ids/createSpecId.ts';
 import type { MaestroPaths } from '#MaestroPaths.ts';
 import { loadSpecTemplate, renderSpecTemplate } from '#specs/template.ts';
-import { isErrnoException } from '#utils/is-errno-exception.ts';
-import { pathExists } from '#utils/path-exists.ts';
 import {
   assertWorkflowState,
   WORKFLOW_PHASES,
@@ -49,10 +47,6 @@ export const createSpec = async ({
   const workflowPath = paths.getWorkflowPath(specId);
   const prototypesPath = paths.getPrototypesPath(specId);
 
-  if (await pathExists(specPath)) {
-    throw new Error(`Spec directory already exists: ${specPath}.`);
-  }
-
   const template = await loadSpecTemplate();
   const spec = renderSpecTemplate({ template, specId, title });
 
@@ -63,12 +57,11 @@ export const createSpec = async ({
   } as const;
 
   assertWorkflowState(state);
-  let created = false;
+
+  await mkdir(paths.getSpecDirectory(), { recursive: true });
+  await mkdir(specPath);
 
   try {
-    await mkdir(paths.getSpecDirectory(), { recursive: true });
-    await mkdir(specPath);
-    created = true;
     await mkdir(prototypesPath, { recursive: true });
     await writeFile(specFilePath, spec, { encoding: 'utf8', flag: 'wx' });
     await writeWorkflowState({
@@ -76,20 +69,10 @@ export const createSpec = async ({
       state,
     });
   } catch (error) {
-    if (!created && isErrnoException(error) && error.code === 'EEXIST') {
-      throw new Error(`Spec directory already exists: ${specPath}.`, {
-        cause: error,
-      });
-    }
-
-    if (created) {
-      throw new Error(
-        `Spec creation failed after creating ${specPath}. Remove this directory before retrying.`,
-        { cause: error },
-      );
-    }
-
-    throw error;
+    throw new Error(
+      `Spec creation failed after creating ${specPath}. Remove this directory before retrying.`,
+      { cause: error },
+    );
   }
 
   return {

package/src/tools/main/resolve-findings.ts

@@ -83,20 +83,21 @@ const formatFindingIds = (findingIds: string[]): string =>
 const formatResolution = (details: FindingResolutionDetails): string => {
   const rejected = formatFindingIds(details.rejectedFindingIds);
   const requiringFix = formatFindingIds(details.findingsRequiringFixIds);
+  const summary = `Recorded rejections for ${rejected}. Findings requiring code fixes: ${requiringFix}.`;
 
   if (details.phase === WORKFLOW_PHASES.DRAFTING_SPEC) {
     const requiringRevision = formatFindingIds(
       details.findingsRequiringSpecRevisionIds,
     );
 
-    return `Recorded rejections for ${rejected}. Findings requiring code fixes: ${requiringFix}. Findings requiring spec revision: ${requiringRevision}. The workflow is drafting-spec. Revise the same spec with the owner and obtain renewed GREEN FLAG. Then call maestro_mark_spec_ready separately before running the builder.`;
+    return `${summary} Findings requiring spec revision: ${requiringRevision}. The workflow is drafting-spec. Revise the same spec with the owner and obtain renewed GREEN FLAG. Then call maestro_mark_spec_ready separately before running the builder.`;
   }
 
   if (details.phase === WORKFLOW_PHASES.READY_FOR_BUILDER) {
-    return `Recorded rejections for ${rejected}. Findings requiring code fixes: ${requiringFix}. The workflow is ready-for-builder. Run the builder separately.`;
+    return `${summary} The workflow is ready-for-builder. Run the builder separately.`;
   }
 
-  return `Recorded rejections for ${rejected}. Findings requiring code fixes: ${requiringFix}. The workflow is candidate-ready.`;
+  return `${summary} The workflow is candidate-ready.`;
 };
 
 export const registerResolveFindingsTool = (pi: ExtensionAPI): void => {

package/src/tools/main/run-builder.ts

@@ -74,7 +74,7 @@ const readBuilderResult = async ({
       );
     }
 
-    return await buildRunResult({ paths, specId, state });
+    return await readTerminalBuilderResult({ paths, specId, state });
   } catch (error) {
     const message = error instanceof Error ? error.message : String(error);
 
@@ -82,73 +82,63 @@ const readBuilderResult = async ({
   }
 };
 
-const readDoneBuilderResult = async ({
-  paths,
-  specId,
-}: ReadBuilderResultInput): Promise<BuilderRunResult> => {
-  const handoff = await readBuilderHandoff({
-    path: await paths.getActiveBuilderHandoffPath(specId),
-    specId,
-  });
-
-  if (handoff.status !== BUILDER_HANDOFF_STATUSES.DONE) {
-    throw new Error(
-      `Builder handoff status does not match workflow phase "${WORKFLOW_PHASES.READY_FOR_VERIFIER}".`,
-    );
-  }
-
-  return {
-    outcome: BUILDER_HANDOFF_STATUSES.DONE,
-    specId,
-    phase: WORKFLOW_PHASES.READY_FOR_VERIFIER,
-    handoff,
-  };
-};
-
-type BuildRunResultInput = {
+type ReadTerminalBuilderResultInput = {
   paths: MaestroPaths;
   specId: string;
   state: WorkflowState;
 };
 
-const buildRunResult = async ({
+const readTerminalBuilderResult = async ({
   paths,
   specId,
   state,
-}: BuildRunResultInput): Promise<BuilderRunResult> => {
-  if (state.phase === WORKFLOW_PHASES.READY_FOR_VERIFIER) {
-    return await readDoneBuilderResult({ paths, specId });
+}: ReadTerminalBuilderResultInput): Promise<BuilderRunResult> => {
+  if (
+    state.phase !== WORKFLOW_PHASES.READY_FOR_VERIFIER &&
+    state.phase !== WORKFLOW_PHASES.ESCALATION_DECISIONS
+  ) {
+    throw new Error(
+      `Builder returned with unexpected workflow phase "${state.phase}".`,
+    );
   }
 
-  if (state.phase === WORKFLOW_PHASES.ESCALATION_DECISIONS) {
-    const handoff = await readBuilderHandoff({
-      path: await paths.getActiveBuilderHandoffPath(specId),
-      specId,
-    });
+  const handoff = await readBuilderHandoff({
+    path: await paths.getActiveBuilderHandoffPath(specId),
+    specId,
+  });
 
-    if (handoff.status !== BUILDER_HANDOFF_STATUSES.ESCALATION) {
-      throw new Error(
-        `Builder handoff status does not match workflow phase "${state.phase}".`,
-      );
-    }
+  const expectedStatus =
+    state.phase === WORKFLOW_PHASES.READY_FOR_VERIFIER
+      ? BUILDER_HANDOFF_STATUSES.DONE
+      : BUILDER_HANDOFF_STATUSES.ESCALATION;
 
-    if (handoff.escalations.some(({ resolution }) => resolution !== null)) {
-      throw new Error(
-        'Current builder escalations already contain an owner resolution.',
-      );
-    }
+  if (handoff.status !== expectedStatus) {
+    throw new Error(
+      `Builder handoff status does not match workflow phase "${state.phase}".`,
+    );
+  }
 
+  if (state.phase === WORKFLOW_PHASES.READY_FOR_VERIFIER) {
     return {
-      outcome: BUILDER_HANDOFF_STATUSES.ESCALATION,
+      outcome: BUILDER_HANDOFF_STATUSES.DONE,
       specId,
       phase: state.phase,
       handoff,
     };
   }
 
-  throw new Error(
-    `Builder returned with unexpected workflow phase "${state.phase}".`,
-  );
+  if (handoff.escalations.some(({ resolution }) => resolution !== null)) {
+    throw new Error(
+      'Current builder escalations already contain an owner resolution.',
+    );
+  }
+
+  return {
+    outcome: BUILDER_HANDOFF_STATUSES.ESCALATION,
+    specId,
+    phase: state.phase,
+    handoff,
+  };
 };
 
 const formatBuilderResult = (result: BuilderRunResult): string => {

package/src/tools/main/run-verifier.ts

@@ -39,22 +39,17 @@ const RunVerifierToolParameters = Type.Object(
 
 const MILLISECONDS_PER_MINUTE = 60_000;
 
-type CandidateReadyResult = {
-  outcome: typeof WORKFLOW_PHASES.CANDIDATE_READY;
-  specId: string;
-  phase: typeof WORKFLOW_PHASES.CANDIDATE_READY;
-  handoff: VerifierHandoff;
-};
+type VerifierTerminalPhase =
+  | typeof WORKFLOW_PHASES.CANDIDATE_READY
+  | typeof WORKFLOW_PHASES.FINDING_DECISIONS;
 
-type FindingsResult = {
-  outcome: typeof WORKFLOW_PHASES.FINDING_DECISIONS;
+type VerifierRunResult = {
+  outcome: VerifierTerminalPhase;
   specId: string;
-  phase: typeof WORKFLOW_PHASES.FINDING_DECISIONS;
+  phase: VerifierTerminalPhase;
   handoff: VerifierHandoff;
 };
 
-type VerifierRunResult = CandidateReadyResult | FindingsResult;
-
 type ReadTerminalVerifierResultInput = {
   paths: MaestroPaths;
   specId: string;
@@ -65,9 +60,7 @@ const readTerminalVerifierResult = async ({
   paths,
   specId,
   state,
-}: ReadTerminalVerifierResultInput): Promise<
-  CandidateReadyResult | FindingsResult
-> => {
+}: ReadTerminalVerifierResultInput): Promise<VerifierRunResult> => {
   if (
     state.phase !== WORKFLOW_PHASES.CANDIDATE_READY &&
     state.phase !== WORKFLOW_PHASES.FINDING_DECISIONS
@@ -93,16 +86,12 @@ const readTerminalVerifierResult = async ({
     );
   }
 
-  const details = {
+  return {
     specId,
     handoff,
+    outcome: state.phase,
+    phase: state.phase,
   };
-
-  if (state.phase === WORKFLOW_PHASES.CANDIDATE_READY) {
-    return { ...details, outcome: state.phase, phase: state.phase };
-  }
-
-  return { ...details, outcome: state.phase, phase: state.phase };
 };
 
 type ReadVerifierResultInput = {

package/src/utils/path-within-or-equal.ts

@@ -17,9 +17,8 @@ export const isPathWithinOrEqual = ({
   const pathToCandidate = relative(parent, candidate);
 
   return (
-    pathToCandidate === '' ||
-    (!pathToCandidate.startsWith(`..${sep}`) &&
-      pathToCandidate !== '..' &&
-      !isAbsolute(pathToCandidate))
+    !pathToCandidate.startsWith(`..${sep}`) &&
+    pathToCandidate !== '..' &&
+    !isAbsolute(pathToCandidate)
   );
 };

package/src/workflow/builder/resolveEscalations.ts

@@ -6,6 +6,7 @@
 import { readBuilderHandoff } from '#artifacts/builder-handoff/readBuilderHandoff.ts';
 import {
   BUILDER_HANDOFF_STATUSES,
+  type Escalation,
   type EscalationResolution,
 } from '#artifacts/builder-handoff/schema.ts';
 import { writeBuilderHandoff } from '#artifacts/builder-handoff/writeBuilderHandoff.ts';
@@ -20,6 +21,45 @@ export type EscalationDecision = EscalationResolution & {
   escalationId: string;
 };
 
+type ApplyEscalationDecisionsInput = {
+  escalations: Escalation[];
+  decisions: EscalationDecision[];
+};
+
+const applyEscalationDecisions = ({
+  escalations,
+  decisions,
+}: ApplyEscalationDecisionsInput) => {
+  if (escalations.some(({ resolution }) => resolution !== null)) {
+    throw new Error('Current questions already contain an owner resolution.');
+  }
+
+  if (decisions.length === 0)
+    throw new Error('At least one escalation decision is required.');
+
+  const expectedIds = new Set(escalations.map(({ id }) => id));
+  const resolutions = new Map<string, EscalationResolution>();
+
+  for (const { escalationId, ...resolution } of decisions) {
+    if (!expectedIds.has(escalationId))
+      throw new Error(`Unknown escalation ID: "${escalationId}".`);
+
+    if (resolutions.has(escalationId))
+      throw new Error(`Duplicate decision for escalation "${escalationId}".`);
+
+    resolutions.set(escalationId, resolution);
+  }
+
+  return escalations.map((escalation) => {
+    const resolution = resolutions.get(escalation.id);
+
+    if (resolution === undefined)
+      throw new Error(`Missing decision for escalation "${escalation.id}".`);
+
+    return { ...escalation, resolution };
+  });
+};
+
 type ResolveEscalationsInput = {
   paths: MaestroPaths;
   specId: string;
@@ -51,33 +91,9 @@ export const resolveEscalations = async ({
     throw new Error('Escalation resolution requires an escalation handoff.');
   }
 
-  if (handoff.escalations.some(({ resolution }) => resolution !== null)) {
-    throw new Error('Current questions already contain an owner resolution.');
-  }
-
-  if (decisions.length === 0)
-    throw new Error('At least one escalation decision is required.');
-
-  const expectedIds = new Set(handoff.escalations.map(({ id }) => id));
-  const resolutions = new Map<string, EscalationResolution>();
-
-  for (const { escalationId, ...resolution } of decisions) {
-    if (!expectedIds.has(escalationId))
-      throw new Error(`Unknown escalation ID: "${escalationId}".`);
-
-    if (resolutions.has(escalationId))
-      throw new Error(`Duplicate decision for escalation "${escalationId}".`);
-
-    resolutions.set(escalationId, resolution);
-  }
-
-  const escalations = handoff.escalations.map((escalation) => {
-    const resolution = resolutions.get(escalation.id);
-
-    if (resolution === undefined)
-      throw new Error(`Missing decision for escalation "${escalation.id}".`);
-
-    return { ...escalation, resolution };
+  const escalations = applyEscalationDecisions({
+    escalations: handoff.escalations,
+    decisions,
   });
 
   const nextHandoff = { ...handoff, escalations };

package/src/workflow/transitions.ts

@@ -77,22 +77,21 @@ export const transitionWorkflow = ({
   event,
 }: TransitionWorkflowInput): WorkflowState => {
   assertWorkflowState(state);
-  const current = state;
   const transition = WORKFLOW_TRANSITIONS[event];
 
   if (transition === undefined) {
     throw new Error(`Unknown workflow event: "${event}".`);
   }
 
-  if (!transition.from.includes(current.phase)) {
+  if (!transition.from.includes(state.phase)) {
     throw new Error(
-      `Workflow event "${event}" is not allowed from phase "${current.phase}".`,
+      `Workflow event "${event}" is not allowed from phase "${state.phase}".`,
     );
   }
 
   return {
-    version: current.version,
-    specId: current.specId,
+    version: state.version,
+    specId: state.specId,
     phase: transition.to,
   };
 };

package/src/workflow/verifier/resolveFindings.ts

@@ -18,56 +18,42 @@ import { writeWorkflowState } from '#workflow/state/writeWorkflowState.ts';
 import { transitionWorkflow } from '#workflow/transitions.ts';
 import { getWorkflowEventByVerifierHandoff } from '#workflow/verifier/utils/getWorkflowEventByVerifierHandoff.ts';
 
-type FindingDecisionRejected = {
-  findingId: string;
-  decision: typeof FINDING_DECISIONS.REJECT;
-  reason: string;
-};
-
-type FindingDecisionApproved = {
-  findingId: string;
-  decision: typeof FINDING_DECISIONS.FIX_CODE;
-};
+type SavedFindingDecision = NonNullable<VerifierFinding['decision']>;
 
-type FindingDecisionRevision = {
+export type FindingDecision = SavedFindingDecision & {
   findingId: string;
-  decision: typeof FINDING_DECISIONS.REVISE_SPEC;
-  reason: string;
-  specChange: string;
 };
 
-export type FindingDecision =
-  | FindingDecisionApproved
-  | FindingDecisionRejected
-  | FindingDecisionRevision;
-
 export type ResolvedFindings = {
   findings: VerifierFinding[];
   state: WorkflowState;
   projectRoot: string;
 };
 
-type AssertDecisionsInput = {
+type ApplyFindingDecisionsInput = {
   decisions: FindingDecision[];
   findings: VerifierFinding[];
 };
 
-function assertDecisions({ decisions, findings }: AssertDecisionsInput): void {
+const applyFindingDecisions = ({
+  decisions,
+  findings,
+}: ApplyFindingDecisionsInput): VerifierFinding[] => {
   const expectedIds = new Set(findings.map(({ id }) => id));
-  const seenIds = new Set<string>();
+  const decisionsById = new Map<string, FindingDecision>();
 
   for (const decision of decisions) {
     if (!expectedIds.has(decision.findingId)) {
       throw new Error(`Unknown finding ID: "${decision.findingId}".`);
     }
 
-    if (seenIds.has(decision.findingId)) {
+    if (decisionsById.has(decision.findingId)) {
       throw new Error(
         `Duplicate decision for finding "${decision.findingId}".`,
       );
     }
 
-    seenIds.add(decision.findingId);
+    decisionsById.set(decision.findingId, decision);
 
     if (
       decision.decision === FINDING_DECISIONS.REJECT &&
@@ -79,12 +65,17 @@ function assertDecisions({ decisions, findings }: AssertDecisionsInput): void {
     }
   }
 
-  const missing = findings.find(({ id }) => !seenIds.has(id));
+  const missing = findings.find(({ id }) => !decisionsById.has(id));
 
   if (missing !== undefined) {
     throw new Error(`Missing decision for finding "${missing.id}".`);
   }
-}
+
+  return findings.map((finding) => ({
+    ...finding,
+    decision: getSavedFindingDecision(decisionsById.get(finding.id)),
+  }));
+};
 
 type FindingWorkflow = {
   state: WorkflowState;
@@ -134,62 +125,25 @@ const readFindingWorkflow = async ({
   return { state, handoff };
 };
 
-type BuildFindingWorkflowInput = {
-  workflow: FindingWorkflow;
-  decisions: FindingDecision[];
-};
-
-const buildFindingWorkflow = ({
-  workflow,
-  decisions,
-}: BuildFindingWorkflowInput): FindingWorkflow => {
-  const { state, handoff } = workflow;
-  assertDecisions({ decisions, findings: handoff.findings });
-
-  const decisionsById = new Map(
-    decisions.map((decision) => [decision.findingId, decision]),
-  );
-
-  const findings = handoff.findings.map((finding) => {
-    const decision = decisionsById.get(finding.id);
-
-    if (decision?.decision === FINDING_DECISIONS.REVISE_SPEC) {
-      return {
-        ...finding,
-        decision: {
-          decision: FINDING_DECISIONS.REVISE_SPEC,
-          reason: decision.reason,
-          specChange: decision.specChange,
-        },
-      };
-    }
-
-    if (decision?.decision === FINDING_DECISIONS.REJECT) {
-      return {
-        ...finding,
-        decision: {
-          decision: FINDING_DECISIONS.REJECT,
-          reason: decision.reason.trim(),
-        },
-      };
-    }
-
-    return { ...finding, decision: { decision: FINDING_DECISIONS.FIX_CODE } };
-  });
-
-  const nextHandoff = { ...handoff, findings };
-
-  const nextState = transitionWorkflow({
-    state,
-    event: getWorkflowEventByVerifierHandoff(nextHandoff),
-  });
+const getSavedFindingDecision = (
+  decision: FindingDecision | undefined,
+): SavedFindingDecision => {
+  if (decision?.decision === FINDING_DECISIONS.REVISE_SPEC) {
+    return {
+      decision: FINDING_DECISIONS.REVISE_SPEC,
+      reason: decision.reason.trim(),
+      specChange: decision.specChange,
+    };
+  }
 
-  assertVerifierHandoff({
-    handoff: nextHandoff,
-    specId: state.specId,
-  });
+  if (decision?.decision === FINDING_DECISIONS.REJECT) {
+    return {
+      decision: FINDING_DECISIONS.REJECT,
+      reason: decision.reason.trim(),
+    };
+  }
 
-  return { state: nextState, handoff: nextHandoff };
+  return { decision: FINDING_DECISIONS.FIX_CODE };
 };
 
 type ResolveFindingsInput = {
@@ -203,23 +157,35 @@ export const resolveFindings = async ({
   specId,
   decisions,
 }: ResolveFindingsInput): Promise<ResolvedFindings> => {
-  const currentWorkflow = await readFindingWorkflow({ paths, specId });
+  const { state, handoff } = await readFindingWorkflow({ paths, specId });
 
-  const workflow = buildFindingWorkflow({
-    workflow: currentWorkflow,
+  const findings = applyFindingDecisions({
     decisions,
+    findings: handoff.findings,
+  });
+
+  const nextHandoff = { ...handoff, findings };
+
+  const nextState = transitionWorkflow({
+    state,
+    event: getWorkflowEventByVerifierHandoff(nextHandoff),
+  });
+
+  assertVerifierHandoff({
+    handoff: nextHandoff,
+    specId: state.specId,
   });
 
   const handoffPath = await paths.getActiveVerifierHandoffPath(specId);
-  await writeJson({ path: handoffPath, data: workflow.handoff });
+  await writeJson({ path: handoffPath, data: nextHandoff });
   await writeWorkflowState({
     path: paths.getWorkflowPath(specId),
-    state: workflow.state,
+    state: nextState,
   });
 
   return {
-    findings: workflow.handoff.findings,
-    state: workflow.state,
+    findings,
+    state: nextState,
     projectRoot: paths.getProjectRoot(),
   };
 };

package/templates/spec.md

@@ -25,7 +25,7 @@ Leave local implementation choices, test code, fixtures, mocks, and commands to
 
 ### Edge cases and error handling
 
-<Describe boundary conditions, failures, and required recovery behavior not already covered above. Cover each required case in the acceptance criteria.>
+<Describe boundary conditions, failures, and required recovery behavior not already covered above. Keep these requirements even when existing tests cover their scenarios.>
 
 ## 3. Technical decisions and prototypes
 
@@ -45,16 +45,20 @@ Leave local implementation choices, test code, fixtures, mocks, and commands to
 
 ## 4. Acceptance criteria
 
-<Give each criterion a unique ID and one observable claim. A probe is the scenario used to check that claim. Describe it in plain language.>
+<Inspect existing tests before writing criteria. Omit a criterion only if a test covers the same starting conditions, action, and expected result. Keep criteria when coverage is partial or uncertain. During review, remove criteria already covered by tests. Keep numbering continuous from AC1 and update affected references. Keep required behavior in section 2 even when its criterion is omitted.>
+
+<Give each criterion a unique ID, one observable claim, and one coverage label. A probe is the scenario used to check that claim. Describe it in plain language. Use success for a valid action that produces the required result. Use failure for an invalid action that is correctly rejected. Use unchanged when the criterion explicitly checks existing behavior that the change must preserve. The label describes the scenario, not the test outcome. A failure scenario passes when the invalid action is correctly rejected. Do not require all three categories.>
 
 ### AC1: <short observable claim>
 
-1. Probe: <starting conditions and action or observation, without prescribing test implementation>
-2. Expected result: <observable and measurable outcome>
-3. Example: <specific starting conditions, concrete input or action, and exact expected result for this probe, not a restatement of the claim>
+1. Coverage: <success | failure | unchanged>
+2. Probe: <starting conditions and action or observation, without prescribing test implementation>
+3. Expected result: <observable and measurable outcome>
+4. Example: <specific starting conditions, concrete input or action, and exact expected result for this probe, not a restatement of the claim>
 
 <!--
 Example:
+Coverage: success
 Probe: Save a change to an item's title, then reopen the item.
 Expected result: The saved title is still present.
 Example: An item's title is "Draft". Change it to "Ready", save, and reopen the item. The title is "Ready".