refactor: rename config options (verify→caution, effort→curiosity, patience→perfection)

Author: cowwoc

.cat/issues/v2/v2.1/implement-caution-test-levels/index.json

@@ -0,0 +1 @@
+{"status": "open", "dependencies": ["2.1-rename-config-options"]}

.cat/issues/v2/v2.1/implement-caution-test-levels/plan.md

@@ -0,0 +1,55 @@
+# Plan
+
+## Goal
+
+Implement the caution level test execution tiers so each level determines how much verification runs
+before the approval gate. Currently caution maps to the old `verify` level (NONE/CHANGED/ALL) which
+controlled file scope, not test depth. This issue redefines the behavior in terms of test depth:
+
+## Caution Level Definitions
+
+### low — compile only (fastest feedback)
+
+Verification runs:
+1. Pre/post condition checks (plan.md post-conditions evaluated against implementation)
+2. Compilation: `mvn -f client/pom.xml compile` — confirms the code builds without errors
+
+Unit tests and E2E tests are skipped. Suitable for simple refactors and documentation changes where
+the user prioritizes speed over coverage confidence.
+
+### medium — compile + unit tests (current default behavior)
+
+Verification runs:
+1. Pre/post condition checks
+2. Compilation: `mvn -f client/pom.xml compile`
+3. Unit tests: `mvn -f client/pom.xml test` — runs the full unit test suite
+
+E2E tests are skipped. This is the current behavior and matches what most issues need.
+
+### high — compile + unit tests + E2E tests (maximum confidence)
+
+Verification runs:
+1. Pre/post condition checks
+2. Compilation: `mvn -f client/pom.xml compile`
+3. Unit tests: `mvn -f client/pom.xml test`
+4. E2E tests: invoke the built jlink artifacts against a real worktree scenario to confirm the change
+   works end-to-end in its actual runtime context (not just unit-level)
+
+The E2E invocation runs the same verification described in each issue's E2E post-condition. The verify
+subagent is responsible for determining the appropriate E2E command from the issue's plan.md.
+
+## Pre-conditions
+
+(none)
+
+## Post-conditions
+
+- [ ] caution=low: verify phase runs pre/post condition checks and `mvn compile`; `mvn test` skipped
+- [ ] caution=medium: verify phase runs pre/post condition checks, `mvn compile`, and `mvn test` (current behavior)
+- [ ] caution=high: verify phase runs pre/post condition checks, `mvn compile`, `mvn test`, and E2E tests
+- [ ] Compilation step (`mvn compile`) added as an explicit verify step (currently absent)
+- [ ] E2E test execution is gated on caution=high
+- [ ] Verify subagent reads caution level from effective config before deciding which steps to run
+- [ ] Unit tests for caution level routing logic in the verify subagent/handler
+- [ ] No regressions in existing caution=medium workflows
+- [ ] E2E: run /cat:work at caution=low and confirm only compile runs; caution=medium confirm unit tests run; caution=high confirm E2E step executes

.cat/issues/v2/v2.1/implement-curiosity-review-scope/index.json

@@ -0,0 +1 @@
+{"status": "open", "dependencies": ["2.1-rename-config-options"]}

.cat/issues/v2/v2.1/implement-curiosity-review-scope/plan.md

@@ -0,0 +1,67 @@
+# Plan
+
+## Goal
+
+Implement the curiosity level review scope so each level determines how broadly stakeholder review and
+research considers system context when evaluating an issue. Currently curiosity maps to the old `effort`
+level which controlled planning depth, not review scope. This issue redefines behavior in terms of
+automatic vs. manual triggering and narrow vs. holistic analysis scope.
+
+## Curiosity Level Definitions
+
+### low — skip automatic review (user-triggered only)
+
+Stakeholder review and research do NOT run automatically as part of `/cat:work`.
+They only run if the user explicitly invokes them (e.g., `/cat:stakeholder-review-agent` directly).
+
+Suitable for highly-trusted teams with established code review processes who find the automated review
+cycle adds friction without value.
+
+### medium — automatic, scoped to immediate issue (current default behavior)
+
+Stakeholder review and research run automatically as part of `/cat:work`.
+
+Scope is limited to:
+- Files changed in the implementation
+- Direct dependencies referenced in the changed files
+- The issue's own plan.md post-conditions and goal
+
+Reviewers are instructed to focus on: "Does this change correctly and completely implement its stated
+goal without introducing regressions in the changed files and their direct dependencies?"
+
+This is the current behavior.
+
+### high — automatic, holistic system integration
+
+Stakeholder review and research run automatically as part of `/cat:work`.
+
+Scope is expanded to consider the broader system:
+- How does this change interact with other open issues in the same version?
+- Are there architectural patterns in the rest of the codebase that this change should follow or
+  that this change might inadvertently break?
+- Are there cross-cutting concerns (security, performance, accessibility) that need validation
+  beyond the immediately changed files?
+
+Reviewer prompts include explicit instructions to read surrounding code context (not just the diff)
+and consider downstream impact on consumers of changed APIs or interfaces.
+
+Research (`cat:research-agent`) also runs with broader context:
+- Surveys existing patterns in the codebase before proposing an approach
+- Checks whether similar problems have been solved elsewhere in the repo
+
+## Pre-conditions
+
+(none)
+
+## Post-conditions
+
+- [ ] curiosity=low: stakeholder review and research are skipped in /cat:work; no automatic invocation
+- [ ] curiosity=low: user can still manually trigger review via explicit skill invocation
+- [ ] curiosity=medium: stakeholder review runs automatically, scoped to changed files and direct deps (current behavior preserved)
+- [ ] curiosity=high: stakeholder review runs with expanded scope; reviewer prompts include explicit instructions to consider broader system context
+- [ ] curiosity=high: research skill (cat:research-agent) is invoked with broader codebase survey context
+- [ ] curiosity=high reviewer prompts: each stakeholder receives instructions to read surrounding files and consider downstream impact
+- [ ] curiosity level read from effective config in work-with-issue orchestration before spawning reviewers
+- [ ] Unit tests for curiosity level routing logic
+- [ ] No regressions in existing curiosity=medium workflows
+- [ ] E2E: run /cat:work at curiosity=low and verify no review runs; curiosity=medium verify scoped review; curiosity=high verify holistic reviewer prompt is used

.cat/issues/v2/v2.1/implement-trust-approval-gates/index.json

@@ -0,0 +1 @@
+{"status": "open", "dependencies": ["2.1-rename-config-options"]}

.cat/issues/v2/v2.1/implement-trust-approval-gates/plan.md

@@ -0,0 +1,65 @@
+# Plan
+
+## Goal
+
+Implement the trust level approval gate model so each level maps to a qualitatively distinct number of
+checkpoints. Currently all three levels only differ in whether the merge gate is shown; this issue
+introduces a pre-implementation gate for `low` and removes all gates for `high`.
+
+## Trust Level Definitions
+
+### low — 2 checkpoints (maximum control)
+
+**Gate 1: Pre-implementation review**
+
+Before the implementation subagent is spawned, present the user with:
+- Issue goal (from plan.md `## Goal`)
+- Post-conditions (from plan.md `## Post-conditions`)
+- Estimated token cost
+
+Options: `Approve and start`, `Request changes`, `Abort`
+
+Only on `Approve and start` does implementation proceed. On `Request changes`, pause for user to
+revise the plan. On `Abort`, release lock and exit.
+
+**Gate 2: Pre-merge review (standard approval gate)**
+
+After implementation, confirm, and review phases: present the diff, stakeholder concerns, and commit
+summary, then ask for merge approval as today.
+
+### medium — 1 checkpoint (current default behavior)
+
+No pre-implementation gate. Only the standard pre-merge approval gate after implementation completes.
+Behavior is identical to the current `trust=medium` workflow.
+
+### high — 0 checkpoints (auto-merge on clean review)
+
+No user approval gates at all. After stakeholder review:
+
+| Stakeholder verdict | Action |
+|---------------------|--------|
+| APPROVED (no concerns) | Auto-merge immediately |
+| CONCERNS (medium/low only) | Auto-merge immediately |
+| CONCERNS (high severity) | Pause — present concerns to user, ask: `Approve and merge` / `Fix concerns` / `Abort` |
+| REJECTED | Pause — present rejection reasons, ask: `Fix issues` / `Abort` |
+
+The auto-merge path still runs squash and rebase onto the target branch before merging.
+
+## Pre-conditions
+
+(none)
+
+## Post-conditions
+
+- [ ] trust=low: pre-implementation gate shown with issue goal, post-conditions, and estimated tokens
+- [ ] trust=low: implementation does not start until user selects `Approve and start`
+- [ ] trust=low: `Request changes` at pre-implementation gate returns control to user without starting work
+- [ ] trust=low: standard pre-merge gate shown after implementation (unchanged)
+- [ ] trust=medium: no pre-implementation gate; only standard pre-merge gate (current behavior preserved)
+- [ ] trust=high: no approval gates when stakeholder verdict is APPROVED or CONCERNS (low/medium severity only)
+- [ ] trust=high with HIGH severity CONCERNS: pauses and presents concerns before proceeding
+- [ ] trust=high with REJECTED verdict: pauses and presents rejection reasons before proceeding
+- [ ] trust=high auto-merge path: squash and rebase onto target branch execute before merge
+- [ ] Unit tests covering gate routing logic for each trust level
+- [ ] No regressions in existing trust=medium workflows
+- [ ] E2E: run /cat:work at trust=low and verify two gates appear; trust=medium verify one gate; trust=high verify auto-merge on APPROVED

.cat/issues/v2/v2.1/rename-config-options/index.json

@@ -1,3 +1,5 @@
 {
-  "status" : "open"
-}
+  "status" : "closed",
+  "resolution" : "implemented",
+  "target_branch" : "v2.1"
+}

.cat/issues/v2/v2.1/rename-config-options/plan.md

@@ -16,7 +16,63 @@ as part of a broader UX redesign that models user personality/style. A companion
 ## Scope
 
 All files under `plugin/` that read or document `effort`, `verify`, or `patience` config keys, plus the
-config template and migration infrastructure.
+config template, Java source in `client/`, and migration infrastructure.
+
+## Research Findings
+
+### Files Requiring Changes
+
+**Config template:**
+- `plugin/templates/config.json` — JSON keys `verify`, `effort`, `patience`
+
+**Java source (production):**
+- `client/src/main/java/io/github/cowwoc/cat/hooks/Config.java` — accessors `getVerify()`, `getEffort()`,
+  `getPatience()` with string literals `"verify"`, `"effort"`, `"patience"` and default values in DEFAULTS map
+- `client/src/main/java/io/github/cowwoc/cat/hooks/util/VerifyLevel.java` — rename to `CautionLevel.java`
+- `client/src/main/java/io/github/cowwoc/cat/hooks/util/EffortLevel.java` — rename to `CuriosityLevel.java`
+- `client/src/main/java/io/github/cowwoc/cat/hooks/util/PatienceLevel.java` — rename to `PerfectionLevel.java`
+- `client/src/main/java/io/github/cowwoc/cat/hooks/skills/GetInitOutput.java` — references `effort patience`
+  in argument parsing
+
+**Java source (tests):**
+- `client/src/test/java/io/github/cowwoc/cat/hooks/test/ConfigTest.java` — references to all three keys
+- `client/src/test/java/io/github/cowwoc/cat/hooks/test/HandlerOutputTest.java` — may reference config keys
+- `client/src/test/java/io/github/cowwoc/cat/hooks/test/CheckDataMigrationTest.java` — migration validation
+
+**Plugin skills reading config via grep/sed:**
+- `plugin/skills/work-review-agent/first-use.md` — greps for `"verify"` and `"patience"`
+- `plugin/skills/work-implement-agent/first-use.md` — greps for `"effort"`
+- `plugin/skills/stakeholder-review-agent/first-use.md` — greps for `"effort"`
+- `plugin/skills/add-agent/first-use.md` — reads config via get-config-output
+
+**Plugin skills with config documentation/menus:**
+- `plugin/skills/config/first-use.md` — config wizard menus for verify, effort, patience
+- `plugin/skills/init/first-use.md` — config template documentation
+
+**Migration:**
+- `plugin/migrations/2.1.sh` — existing migration has `curiosity → effort` rename (lines 483-497) that
+  needs reversal; also references `verify` in session migration (lines 908-910)
+- `plugin/migrations/registry.json` — migration descriptions reference old names
+
+**Concepts and rules referencing config keys:**
+- Various `plugin/concepts/*.md` and `plugin/rules/*.md` files that document `verify`, `effort`, `patience`
+- `plugin/agents/work-verify.md` — references verify level
+
+### Scale Inversion for perfection
+
+The `patience` config controlled "how long to wait" (high=wait long, low=act fast). The replacement
+`perfection` controls "how immediately to act on improvements" (high=act immediately, low=defer). This is
+a semantic inversion: `patience: high` maps to `perfection: low` and vice versa. The migration script must
+invert the value during conversion.
+
+### Existing Migration Context
+
+The `2.1.sh` migration already contains a `curiosity → effort` rename (Phase 6, lines 483-497). Since this
+issue renames `effort → curiosity` (reversing that), the migration phase needs to be removed or updated to
+be a no-op for this key. The migration must now handle:
+- `verify → caution`
+- `effort → curiosity`
+- `patience → perfection` (with value inversion: high↔low, medium stays medium)
 
 ## Post-conditions
 
@@ -31,3 +87,110 @@ config template and migration infrastructure.
 - `plugin/skills/config/first-use.md` updated to use new names in all menus and descriptions
 - `plugin/skills/init/first-use.md` updated to use new names
 - Config documentation reflects new names and their meanings
+
+## Sub-Agent Waves
+
+### Wave 1
+
+1. **Rename Java enum classes** (file renames + content updates):
+   - Rename `client/src/main/java/io/github/cowwoc/cat/hooks/util/VerifyLevel.java` to `CautionLevel.java`:
+     change class name `VerifyLevel` → `CautionLevel`, update Javadoc from "verify level" to "caution level",
+     update method name `fromString` Javadoc, keep same enum values (NONE, CHANGED, ALL)
+   - Rename `client/src/main/java/io/github/cowwoc/cat/hooks/util/EffortLevel.java` to `CuriosityLevel.java`:
+     change class name `EffortLevel` → `CuriosityLevel`, update Javadoc from "effort level" to
+     "curiosity level", keep same enum values (LOW, MEDIUM, HIGH)
+   - Rename `client/src/main/java/io/github/cowwoc/cat/hooks/util/PatienceLevel.java` to
+     `PerfectionLevel.java`: change class name `PatienceLevel` → `PerfectionLevel`, update Javadoc from
+     "patience level" to "perfection level" with note about inverted scale (high=act immediately, low=defer),
+     keep same enum values (LOW, MEDIUM, HIGH)
+
+2. **Update Config.java**:
+   - In DEFAULTS map: change keys `"verify"` → `"caution"`, `"effort"` → `"curiosity"`,
+     `"patience"` → `"perfection"`
+   - Rename accessor `getVerify()` → `getCaution()`, return type `VerifyLevel` → `CautionLevel`,
+     string literal `"verify"` → `"caution"`
+   - Rename accessor `getEffort()` → `getCuriosity()`, return type `EffortLevel` → `CuriosityLevel`,
+     string literal `"effort"` → `"curiosity"`
+   - Rename accessor `getPatience()` → `getPerfection()`, return type `PatienceLevel` → `PerfectionLevel`,
+     string literal `"patience"` → `"perfection"`
+   - Update all import statements for renamed enum classes
+
+3. **Update GetInitOutput.java**:
+   - Change argument references from `effort patience` to `curiosity perfection`
+   - Update any string literals referencing old names
+
+4. **Update all Java files that import or reference the old enum classes**:
+   - Search for `import.*VerifyLevel`, `import.*EffortLevel`, `import.*PatienceLevel` across all Java files
+   - Update imports and usages to new class names
+   - Search for `getVerify()`, `getEffort()`, `getPatience()` across all Java files and update to new names
+
+5. **Update Java tests**:
+   - `ConfigTest.java`: update all references to old key names (`"verify"`, `"effort"`, `"patience"`) to new
+     names, update enum class references, update method call names
+   - `HandlerOutputTest.java`: update any references to old config keys or enum classes
+   - `CheckDataMigrationTest.java`: update migration test expectations
+   - Any other test files that reference the old names
+
+6. **Run `mvn -f client/pom.xml verify -e`** to ensure all Java changes compile and tests pass
+
+7. **Commit Java changes**:
+   `refactor: rename config option types verify→caution, effort→curiosity, patience→perfection`
+
+### Wave 2
+
+1. **Update config template**:
+   - In `plugin/templates/config.json`: rename keys `"verify"` → `"caution"`, `"effort"` → `"curiosity"`,
+     `"patience"` → `"perfection"`
+
+2. **Update plugin skills that grep config values** (change grep patterns from old to new key names):
+   - `plugin/skills/work-review-agent/first-use.md`: change `'"verify"'` grep to `'"caution"'`,
+     change `'"patience"'` grep to `'"perfection"'`
+   - `plugin/skills/work-implement-agent/first-use.md`: change `'"effort"'` grep to `'"curiosity"'`
+   - `plugin/skills/stakeholder-review-agent/first-use.md`: change `'"effort"'` grep to `'"curiosity"'`
+   - `plugin/skills/add-agent/first-use.md`: update any config key references
+
+3. **Update config wizard skill**:
+   - `plugin/skills/config/first-use.md`: rename all menu items and descriptions from
+     `verify` → `caution`, `effort` → `curiosity`, `patience` → `perfection`.
+     Update the step names and emoji descriptions to match new personality-oriented naming.
+     For perfection, update the scale description to: high=act immediately on improvements, low=defer.
+
+4. **Update init skill**:
+   - `plugin/skills/init/first-use.md`: update config template documentation to use new key names
+
+5. **Update migration script** (`plugin/migrations/2.1.sh`):
+   - Remove or update the existing `curiosity → effort` Phase 6 migration (lines 483-497) since the rename
+     is now reversed
+   - Add new migration phase that renames: `verify → caution`, `effort → curiosity`, `patience → perfection`
+   - For `patience → perfection`, invert the value: `high` → `low`, `low` → `high`, `medium` → `medium`
+   - Make the migration idempotent: check if old keys exist before renaming, skip if already renamed
+   - Update `plugin/migrations/registry.json` descriptions if needed
+
+6. **Update concept and rule files** that reference config keys:
+   - Search `plugin/concepts/` and `plugin/rules/` for references to `verify` (as config key), `effort`,
+     `patience` and update to new names
+   - Be careful to only change config-key references, NOT the English word "verify" when used as a verb
+     (e.g., "verify implementation" should NOT be changed)
+
+7. **Commit plugin changes**:
+   `refactor: rename config keys verify→caution, effort→curiosity, patience→perfection in plugin`
+
+8. **Fix work-agent config field reference**:
+   - In `plugin/skills/work-agent/first-use.md` line 69: change the `"verify"` field name reference to `"caution"`
+     so the documentation correctly identifies the config key that VERIFY/CAUTION is read from
+
+9. **Fix work-review-agent documentation references**:
+   - In `plugin/skills/work-review-agent/first-use.md` lines 174, 176, 186, 188: change all occurrences of
+     `verify=none` to `caution=none` so the documentation about the config setting uses the renamed key
+
+10. **Update index.json**: set status to `closed`, progress to 100%
+
+## Success Criteria
+
+- `mvn -f client/pom.xml verify -e` passes with zero errors
+- `plugin/templates/config.json` contains only `caution`, `curiosity`, `perfection` (not the old names)
+- No Java file references `VerifyLevel`, `EffortLevel`, or `PatienceLevel` class names
+- No skill file greps for `"verify"`, `"effort"`, or `"patience"` as config keys
+- Migration script in `plugin/migrations/2.1.sh` handles old→new key conversion with value inversion for
+  perfection
+- Migration is idempotent (running twice produces same result)