create-claude-rails 0.5.7 → 0.5.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-claude-rails",
-  "version": "0.5.7",
+  "version": "0.5.8",
   "description": "Claude on Rails — opinionated process scaffolding for Claude Code projects",
   "bin": {
     "create-claude-rails": "bin/create-claude-rails.js"

package/templates/README.md

@@ -22,7 +22,7 @@ whole system work out of the box. Wave 6 documents how Flow extends
 and will adopt the package — see [EXTENSIONS.md](EXTENSIONS.md) for
 annotated phase file overrides, reusable patterns, and perspective
 writing examples. Wave 7 adds the lifecycle layer — onboarding,
-capability seeding, upgrades, and box health monitoring.
+capability seeding, upgrades, and CoR health monitoring.
 
 Everything is organized to mirror the `.claude/` directory structure, so
 adoption is straightforward: copy what you need into your project's
@@ -106,7 +106,7 @@ execution, audit). Each is a named domain expert encoded in markdown.
 
 | Perspective | Domain | Activation |
 |------------|--------|-----------|
-| `box-health` | CoR adoption health, phase file coverage, configuration drift, anti-bloat | Always-on during audit |
+| `cor-health` | CoR adoption health, phase file coverage, configuration drift, anti-bloat | Always-on during audit |
 
 **Infrastructure files (7):**
 
@@ -430,7 +430,7 @@ This package includes all 7 waves of the extraction:
    reusable patterns, perspective writing guide with 3 examples)
 7. **Lifecycle layer** — done (onboard skeleton for project adoption with
    3-mode re-runnability, seed skeleton for capability seeding from tech
-   signals, upgrade skeleton for conversational box updates, box-health
+   signals, upgrade skeleton for conversational box updates, cor-health
    perspective for adoption monitoring, pib-db enhancements: status
    tracking, tags, update-action command, migration logic)
 

package/templates/skills/debrief/SKILL.md

@@ -246,7 +246,72 @@ generalizable pattern, perspective, or convention? If so, mention
 `/extract` as an option for proposing it upstream to CoR. This is
 rarer than project-specific skills.
 
-### 10. Capture Loose Ends (core)
+### 10. Perspective Check (core)
+
+Silently reflect: is this project's expertise coverage still right
+for what it's actually doing?
+
+This is the anti-entropy mechanism for the perspective cabinet. Without
+it, a project can adopt a framework, start handling sensitive data, or
+grow complex enough to need architectural review — and none of the
+relevant expertise ever activates because nobody ran `/seed`.
+
+**Two checks, both silent unless they find something:**
+
+**Check A — Uncovered technology.** Quickly scan what this session
+touched. Did the work involve a framework, library, data store, or
+infrastructure that isn't covered by any existing perspective? Compare
+against the perspectives in `.claude/skills/perspectives/` and the
+groups in `_groups.yaml`.
+
+Examples of what to catch:
+- Session used Mantine components but there's no framework-quality
+  perspective
+- Session wrote database queries but there's no data-integrity
+  perspective
+- Session built UI but accessibility isn't in any active group
+
+**Check B — Dormant perspective that should be active.** Are there
+perspectives installed in the project that aren't in any `_groups.yaml`
+group, but based on the last few sessions, probably should be? A
+perspective sitting dormant while the project does exactly the kind of
+work it's designed to review is a waste.
+
+**Most sessions: nothing.** These checks should be completely silent
+when nothing is off. Don't mention perspectives if everything is fine.
+
+**When there's a gap:** Explain it plainly — no jargon about
+"perspectives" or "cabinets." Talk about what the project is missing
+in terms of what it would DO for them:
+
+> "You've been building UI for the last few sessions, but nothing is
+> checking whether it works well on phones or is usable for people
+> with accessibility needs. I can set that up so it gets checked
+> automatically when you run quality reviews. Want me to?"
+
+or:
+
+> "You're using Mantine a lot now. There's a specialist review that
+> checks whether you're getting the full value from it — catching
+> things like hand-rolling components that Mantine already provides.
+> Want me to turn that on?"
+
+or:
+
+> "This project has gotten complex enough that it might help to have
+> something watching whether the overall architecture still makes
+> sense as it grows. Want me to set that up?"
+
+If the user says yes, either:
+- Activate a dormant perspective (add it to `_groups.yaml`)
+- Run `/seed` to build a new one
+- Install a Tier 3 perspective that isn't in the project yet
+
+If the user says no, move on. Don't re-suggest the same gap next
+session. Track declined suggestions in system-status.md or equivalent
+so you don't nag.
+
+### 11. Capture Loose Ends (core)
 
 Read `phases/loose-ends.md` for non-project items and environmental
 concerns to capture before closing. Sessions generate non-project
@@ -255,14 +320,14 @@ these aren't captured somewhere, they rely on human memory.
 
 **Skip (absent/empty).**
 
-### 11. Discover Custom Phases
+### 12. Discover Custom Phases
 
 After running the core phases above, check for any additional phase
 files in `phases/` that the skeleton doesn't define. These are project-
 specific extensions. Each custom phase file declares its position in
 the workflow. Execute them at their declared position.
 
-### 12. Present Report (presentation)
+### 13. Present Report (presentation)
 
 Read `phases/report.md` for how to present the debrief summary.
 
@@ -294,7 +359,7 @@ skip presentation phases. Core phases always run.
 
 - **Core phases** (always run): inventory, close-work, auto-maintenance,
   update-state, health-checks, record-lessons, upstream-feedback,
-  skill-discovery, loose-ends, persist work
+  skill-discovery, perspective-check, loose-ends, persist work
 - **Presentation phases** (skippable): report
 
 A project that wants a quick debrief variant skips the report and

package/templates/skills/onboard/SKILL.md

@@ -256,7 +256,7 @@ looked like before, what changed, and why.
 
 Read `phases/post-onboard-audit.md` for the configuration sanity check.
 
-**Default (absent/empty):** Run a lightweight audit from the box-health
+**Default (absent/empty):** Run a lightweight audit from the cor-health
 perspective, scoped to what was just generated. Checks interview–config
 coherence (did mentioned technologies get wired into phase files?),
 module–phase alignment (do phase files reference skipped modules?),
@@ -279,7 +279,7 @@ pre-flight check, not a deferred finding.
 | `generate-session-loop.md` | Default: wire orient/debrief phases | How to set up the session loop |
 | `modularity-menu.md` | Default: present module hierarchy | Which modules to present and how |
 | `summary.md` | Default: present changes + next steps | How to present results |
-| `post-onboard-audit.md` | Default: box-health sanity check | What to verify after generation |
+| `post-onboard-audit.md` | Default: cor-health sanity check | What to verify after generation |
 
 ## Conversational Stance
 

package/templates/skills/onboard/phases/post-onboard-audit.md

@@ -1,7 +1,7 @@
 # Post-Onboard Audit — Configuration Sanity Check
 
 After generating all files and presenting the summary, run a lightweight
-audit from the box-health perspective to catch configuration issues before
+audit from the cor-health perspective to catch configuration issues before
 the user starts their first session.
 
 When this file is absent or empty, the default behavior is: run the audit
@@ -20,7 +20,7 @@ starts relying on the configuration.
 
 ## What to Check
 
-Run as the **box-health perspective** but scoped to what onboard just
+Run as the **cor-health perspective** but scoped to what onboard just
 generated. This is NOT a full audit — it's a focused sanity check on
 the fresh configuration.
 
@@ -111,7 +111,7 @@ finding — it's a pre-flight check.
 
 ## What This Is NOT
 
-- **Not a full box-health audit.** That runs periodically via /audit and
+- **Not a full cor-health audit.** That runs periodically via /audit and
   covers telemetry, usage patterns, drift over time. This only checks
   what was just generated.
 - **Not a product quality review.** Whether the _context.md is well-written

package/templates/skills/perspectives/_groups-template.yaml

@@ -46,4 +46,4 @@ groups:
   #     - process
   #     - documentation
   #     - meta-process
-  #     - box-health          # CoR adoption health, configuration drift, anti-bloat
+  #     - cor-health          # CoR adoption health, configuration drift, anti-bloat

package/templates/skills/perspectives/{box-health → cor-health}/SKILL.md

@@ -1,7 +1,7 @@
 ---
-name: perspective-box-health
+name: perspective-cor-health
 description: |
-  Box adoption and configuration health analyst. Evaluates whether Claude on Rails is
+  CoR adoption and configuration health analyst. Evaluates whether Claude on Rails is
   configured correctly for this project — phase file coverage, perspective
   activation patterns, skill usage, configuration drift, anti-bloat.
   Different from meta-process (skill quality) — this checks adoption fitness.
@@ -14,7 +14,7 @@ files:
   - .claude/skills/perspectives/_groups.yaml
   - .claude/hooks/*.sh
 topics:
-  - box health
+  - cor health
   - adoption
   - configuration
   - phase coverage
@@ -33,7 +33,7 @@ related:
     role: "Adjacent perspective — skill quality (not adoption health)"
 ---
 
-# Box Health
+# CoR Health
 
 See `_context.md` for shared perspective context.
 
@@ -79,7 +79,7 @@ the *current state* of the project it serves.
 - **Files:** `.claude/skills/*/SKILL.md`, `.claude/skills/*/phases/*.md`,
   `.claude/skills/perspectives/*/SKILL.md`, `.claude/skills/perspectives/_groups.yaml`,
   `.claude/hooks/*.sh`
-- **Topics:** box health, adoption, configuration, phase coverage, bloat,
+- **Topics:** cor health, adoption, configuration, phase coverage, bloat,
   retirement, drift
 
 Also activates when: