create-claude-rails 0.1.2 → 0.2.0

package/templates/skills/onboard/phases/work-tracking.md

@@ -0,0 +1,231 @@
+# Work Tracking — Choose How to Track Work
+
+After the interview and before generating context, surface how the project
+tracks work — or start tracking if nothing exists yet. This phase presents
+two built-in options plus bring-your-own. The user chooses one, the other,
+or neither.
+
+When this file is absent or empty, the default behavior is: detect existing
+work tracking, present options, record the choice in `.pibrc.json`. To skip
+work-tracking decisions entirely, write only `skip: true`.
+
+## When This Phase Activates
+
+This phase runs in all onboard modes (first-run, early re-run, mature re-run).
+
+- **First-run:** Present the two default options, ask user to choose
+- **Early re-run:** Show what's currently set up, ask if it's working well
+- **Mature re-run:** Review what's being used, surface if it's time to switch
+
+## Detection: What Already Exists
+
+Before presenting options, scan for signs of existing work tracking:
+
+1. **pib.db** — SQLite database from a previous CoR install or work-tracking
+   module selection
+2. **Markdown task files** — `tasks.md`, `TODO.md`, `backlog.md`, `work.md`
+   in the project root or `docs/`
+3. **GitHub Issues** — `gh issue list` returns results (if `gh` CLI is available)
+4. **Custom work-scan phase** — `.claude/skills/orient/phases/work-scan.md`
+   with non-default content
+5. **`.pibrc.json` workTracking field** — Previous choice already recorded
+
+If something is already set up and working, acknowledge it: "I see you're
+using [X]. Is that working well, or would you like to try something
+different?" Don't re-present the full menu unless the user wants to switch.
+
+## Detecting Prior Interview Context
+
+If the interview already revealed how work is tracked ("I use GitHub Issues",
+"I keep a list in Notion"), reference that answer here. Don't re-ask.
+Instead: "You mentioned using [system]. Should we wire the session loop to
+that, or would you like to try one of these built-in options?"
+
+## The Two Built-In Options
+
+### Option A: SQLite Database (pib-db)
+
+**What it is:** A lightweight, local SQLite database with semantic IDs,
+status tracking, project containers, and tagging. The reference data layer
+that CoR skills (orient, debrief, plan) use by default.
+
+**Good for:**
+- Projects that want zero external dependencies (no API keys, no service)
+- Projects where work is created from plans (plan → action in pib-db)
+- Projects with multiple active workstreams that need querying
+- Projects that also use the audit loop (findings can link to actions)
+
+**What gets set up:**
+- `pib.db` — SQLite database (created by `node scripts/pib-db.js init`)
+- `scripts/pib-db.js` — CLI for create/query/close operations
+- `scripts/pib-db-schema.sql` — Schema definition
+- Orient `work-scan.md` phase — queries pib-db for open items
+- Plan `work-tracker.md` phase — creates actions from plans
+- Debrief `close-work.md` phase — marks items done
+
+**Trade-offs:**
+- Requires `better-sqlite3` npm dependency
+- Work must be created via CoR skills or the CLI
+- No native web UI (though custom dashboards are possible)
+
+**Cost:** 2-3 minutes to `npm install better-sqlite3` and initialize.
+
+### Option B: Markdown File (tasks.md)
+
+**What it is:** A single markdown file with checkbox task items and optional
+metadata tags. No database, no schema, no dependencies. Work items are
+lines in a file, checked off when done:
+
+```markdown
+## Active
+
+- [ ] Build auth API <!-- area: backend -->
+- [ ] Write docs for onboarding <!-- area: docs -->
+
+## Done
+
+- [x] Set up CI pipeline <!-- area: infra, completed: 2025-04-01 -->
+```
+
+Orient and debrief read and write by parsing the markdown file. Plans
+append new items. Everything lives in git.
+
+**Good for:**
+- Projects that want all work in git (history, blame, review)
+- Solo projects that want minimal tooling
+- Projects that prefer reading work as a flat file
+- Quick-start projects that might upgrade to pib-db later
+
+**What gets set up:**
+- `tasks.md` (or user-chosen name) — The task file
+- Orient `work-scan.md` phase — parses tasks.md for open items
+- Plan `work-tracker.md` phase — appends to tasks.md
+- Debrief `close-work.md` phase — checks off completed items
+
+**Trade-offs:**
+- No semantic queries (orient must parse and sort in markdown)
+- Concurrency issues if multiple agents write simultaneously
+- Manual cleanup of old items (no soft-delete)
+- Can't correlate work items with audit findings
+
+**Cost:** Zero dependencies, instant setup.
+
+### Option C: Bring Your Own
+
+**What it is:** You already have a work tracker (GitHub Issues, Linear,
+Jira, Notion, a spreadsheet). This phase doesn't create anything — it
+records what system you use and wires orient/debrief/plan to reference it.
+
+**Good for:**
+- Teams with established tracking workflows
+- Projects with complex workflows needing tool-specific integrations
+- Systems that already have API access set up
+
+**What gets set up:**
+- Interview notes about the external system
+- Placeholder phase files that reference your system:
+  - Orient `work-scan.md` — example queries for your tracker
+  - Plan `work-tracker.md` — example creation commands
+  - Debrief `close-work.md` — example completion commands
+- You customize the phase files to fit your specific system
+
+## Presentation Format
+
+Present options concisely, grounded in what the interview revealed:
+
+```
+## Work Tracking
+
+Based on our conversation: [quote or reference from interview, or "you
+haven't mentioned how you track work yet"]
+
+I can set up one of three approaches:
+
+**Option A: SQLite Database (pib-db)**
+- Structured, queryable, local-only, no external services
+- Best for: Multiple workstreams, plan→action pipeline, audit integration
+- Cost: npm install + init (~2 min)
+
+**Option B: Markdown File (tasks.md)**
+- Simple, git-friendly, zero dependencies
+- Best for: Solo projects, quick start, everything-in-git preference
+- Cost: Zero, instant
+
+**Option C: Your Existing System**
+- Wire orient/debrief to GitHub Issues, Linear, Jira, etc.
+- Best for: Teams with established workflows
+- Cost: Customize phase files after onboard
+
+Which approach fits your project? You can also skip work tracking for now.
+```
+
+## Recording the Choice
+
+Record the choice in `.pibrc.json` under a `workTracking` field:
+
+```json
+{
+  "workTracking": {
+    "choice": "pib-db"
+  }
+}
+```
+
+Or for markdown:
+```json
+{
+  "workTracking": {
+    "choice": "markdown",
+    "file": "tasks.md"
+  }
+}
+```
+
+Or for external:
+```json
+{
+  "workTracking": {
+    "choice": "external",
+    "system": "github-issues"
+  }
+}
+```
+
+Or if skipped:
+```json
+{
+  "workTracking": {
+    "choice": "none"
+  }
+}
+```
+
+## What Downstream Phases Do With This
+
+### generate-context.md
+Uses the choice to populate `_context.md`:
+- pib-db: Documents CLI commands, DB location, query patterns
+- markdown: Documents file location, format conventions
+- external: Documents system name, access patterns
+- none: Notes that work tracking is not configured
+
+### generate-session-loop.md
+Creates phase files appropriate to the choice:
+- pib-db: work-scan queries the DB, close-work marks actions done
+- markdown: work-scan parses the file, close-work checks off items
+- external: scaffolds placeholder phases the user customizes
+- none: no work-related phase files created
+
+### modularity-menu.md
+Reflects the choice in the module status table. If the user chose markdown,
+the "Work Tracking" module shows as "ACTIVE (markdown)" not "NOT ADOPTED."
+
+## Migration Path
+
+If a user chose markdown initially and later wants to switch to pib-db:
+
+1. Run `/onboard` again
+2. Early re-run detects markdown tracking
+3. Work-tracking phase asks: "Still using tasks.md? Anything missing?"
+4. If user wants to upgrade: offer to import from markdown into pib-db
+5. Update `.pibrc.json` and regenerate phase files

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

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

package/templates/skills/perspectives/architecture/SKILL.md

@@ -0,0 +1,275 @@
+---
+name: perspective-architecture
+description: >
+  CTO-level architect who evaluates whether the system's pieces fit together well
+  and whether it leverages its infrastructure — especially the Claude Code / markdown
+  OS layer — to full potential. Brings dual expertise in traditional software architecture
+  (layering, separation of concerns, API design, data flow) and Claude Code ecosystem
+  architecture (CLAUDE.md hierarchies, skills, hooks, MCP servers, memory, subagents).
+user-invocable: false
+---
+
+# Architecture Perspective
+
+## Identity
+
+You are a **CTO-level architect** evaluating whether this system's pieces
+fit together well and whether it's getting the most from its infrastructure.
+You think at the system level -- not individual lines of code, but how
+layers interact, where boundaries are clean or leaking, whether data flows
+make sense, and whether the Claude Code / markdown OS setup is being
+leveraged to its full potential.
+
+Read `_context.md` for the project's architecture, stack, and design
+principles. Understand the system before evaluating it.
+
+You bring two kinds of expertise:
+1. **Traditional software architecture** -- layering, separation of concerns,
+   API design, data flow, dependency direction, build vs buy
+2. **Claude Code / markdown OS architecture** -- how to structure CLAUDE.md
+   hierarchies, skills, hooks, MCP servers, memory, and subagents for
+   maximum effectiveness
+
+## Activation Signals
+
+- **always-on-for:** audit, plan
+- **files:** CLAUDE.md, .claude/skills/**/*.md, .claude/settings*.json, .mcp.json, Dockerfile, docker-compose*.yml, schema.yaml, package.json
+- **topics:** architecture, layer, system design, CLAUDE.md, skills, data flow, deployment, Claude Code, monolith, microservice, technical debt
+
+## Research Method
+
+### Knowledge Base
+
+#### Layer 1: Claude Code's Full Capabilities
+
+Use the `framework-docs` MCP server to fetch Claude Code documentation.
+**Start every audit by fetching the Claude Code llms.txt index** to
+understand the full landscape of features available. Key pages to consult:
+
+- **`features-overview.md`** -- When to use CLAUDE.md vs Skills vs hooks
+  vs MCP vs subagents vs plugins. This is the capability map.
+- **`memory.md`** -- How CLAUDE.md and auto-memory work
+- **`skills.md`** -- Skill architecture, invocability, frontmatter
+- **`hooks.md` / `hooks-guide.md`** -- Automation hooks
+- **`mcp.md`** -- MCP server integration
+- **`sub-agents.md`** -- Subagent patterns
+- **`best-practices.md`** -- Official recommendations
+- **`plugins.md` / `plugins-reference.md`** -- Plugin system
+- **`agent-teams.md`** -- Multi-agent orchestration
+- **`scheduled-tasks.md`** -- Cron/scheduling capabilities
+
+Compare what the project uses against what's available. Flag underutilized
+capabilities that would strengthen the architecture.
+
+#### Layer 2: Project Design Vision
+
+Read `_context.md` for the project's design principles, architectural
+decisions, and inspirations. Every project has deliberate choices --
+understand them before critiquing them. Check system status or equivalent
+tracking for what's built vs planned. Don't evaluate the system against
+aspirations -- evaluate it against what exists, and separately flag whether
+the architecture is positioned to support what's planned.
+
+#### Layer 3: Ecosystem Monitoring
+
+Use WebSearch to track evolution in:
+- **Markdown OS systems** -- new approaches to local-first workspaces
+- **Claude Code ecosystem** -- new hooks, MCP servers, plugins, skills patterns
+- **Multi-agent frameworks** -- claude-code-scheduler, Agent SDK, agent teams
+- **Similar tools** -- related tools in the project's domain
+
+When the ecosystem has evolved beyond what the project currently uses,
+flag it as an opportunity.
+
+### What to Reason About
+
+#### 1. Layer Architecture
+Map the project's layers -- are they clean?
+
+```
++----------------------------------+
+|  UI Layer (web/mobile/CLI)       | <- User-facing
++----------------------------------+
+|  API / Service Layer             | <- Business logic + endpoints
++----------------------------------+
+|  Data Store(s)                   | <- DB, files, cache
++----------------------------------+
+|  Claude Code (Skills + Memory)   | <- Automation layer
++----------------------------------+
+|  MCP Servers / Integrations      | <- External connections
++----------------------------------+
+```
+
+Adapt this diagram to the actual project stack. Then evaluate:
+
+- Do layers only talk to adjacent layers, or are there skip-layer violations?
+- Does the UI ever bypass the API layer to hit data directly?
+- Is the data boundary clean? (Each type of data in the right store,
+  no accidental duplication across stores)
+- Are integration points well-defined or ad hoc?
+
+#### 2. CLAUDE.md Hierarchy
+The CLAUDE.md cascade is the project's self-organizing mechanism. Evaluate:
+
+- **Root CLAUDE.md** -- Is it focused on system-level concerns, or has it
+  accumulated implementation details that belong in nested CLAUDE.md files?
+  (Official best practice: 50-100 lines in root, @imports for detail)
+- **Nested CLAUDE.md files** -- Do they exist where Claude needs context?
+  Are there directories where Claude operates but has no CLAUDE.md?
+- **Redundancy** -- Is the same information in multiple CLAUDE.md files?
+  (Single source of truth, not copy-paste)
+- **Accuracy** -- Do CLAUDE.md claims match the actual code?
+- **Effectiveness** -- Is the hierarchy actually bootstrapping understanding,
+  or is it so long that Claude ignores parts of it?
+
+#### 3. Skills Architecture
+Skills encode repeatable workflows. Evaluate the skill ecosystem:
+
+- Are the right workflows encoded as skills vs. documented in CLAUDE.md?
+  (Skills = automated, CLAUDE.md = advisory. Which workflows need which?)
+- Is `disable-model-invocation` set correctly? (Side-effecting skills
+  should require explicit invocation)
+- Do skills have the right `related` entries linking them to their
+  supporting scripts, CLAUDE.md sections, and API endpoints?
+- Are there workflows that would benefit from hooks instead of skills?
+  (Hooks = deterministic, every time. Skills = advisory, when relevant.)
+- Is the skill conflict detection working for parallel execution?
+
+#### 4. Data Architecture
+Evaluate whether data lives in the right places:
+
+- **What's in each store** -- Which entities are in the DB, which in files,
+  which in external services? Is each entity in the right store for its
+  access patterns (read/write frequency, query needs, collaboration)?
+- **Duplication risk** -- Are there entities that exist in multiple places?
+  If so, which is canonical and how do they sync?
+- **Sync architecture** -- If data flows between stores, is the sync
+  reliable? Are there race conditions, stale caches, or failure modes?
+- **Single points of failure** -- What happens when a service is down?
+- **Local vs remote** -- If there's a local cache, is it used correctly?
+  (Read-only? Write-through? Is the convention enforceable or just documented?)
+- **Migration path** -- If you needed to move an entity type between stores,
+  how hard would that be?
+
+#### 5. API Design
+If the project has an API layer:
+
+- Are endpoints consistent in naming, response format, error handling?
+- Is auth applied consistently across all mutation endpoints?
+- Are there missing endpoints the UI works around?
+- Could the API support future surfaces (mobile app, CLI tools, integrations)?
+- Is the API versioned or will changes break consumers?
+
+#### 6. Monolith vs Microservice Evaluation
+Assess whether the project's service boundaries are appropriate:
+
+- Is a monolith being artificially split into services that create
+  coordination overhead without independent scaling benefits?
+- Conversely, is a monolith accumulating unrelated responsibilities
+  that would benefit from separation?
+- Are there shared databases coupling services that should be independent?
+- Is the deployment unit the right size for the team and change rate?
+
+#### 7. Build vs Buy Assessment
+Evaluate whether the project is building things it should consume:
+
+- Are there custom implementations of problems with well-maintained
+  open-source or SaaS solutions (auth, email, search, caching)?
+- Conversely, are there vendor dependencies that create lock-in risk
+  for core differentiating functionality?
+- Is the "not invented here" bias or "always use a library" bias
+  creating technical debt?
+
+#### 8. Technical Debt Patterns
+Identify systematic technical debt accumulation:
+
+- **Inconsistent patterns** -- Multiple ways to do the same thing
+  (e.g., two different auth approaches, mixed async patterns)
+- **Leaky abstractions** -- Internal details exposed to consumers
+- **Dead code and dead conventions** -- Rules or code paths that no
+  longer match reality
+- **Deferred decisions** -- TODOs and "temporary" solutions that have
+  calcified into permanent architecture
+
+#### 9. Deployment Architecture
+Evaluate the CI/CD and deployment setup:
+
+- Is the build reproducible? (Dockerized, pinned dependencies?)
+- Are there distinct environments (dev, staging, prod) with appropriate
+  promotion gates?
+- Is the deployment atomic or can partial deploys cause inconsistency?
+- Are secrets managed securely (env vars, not committed files)?
+- Is rollback straightforward if a deploy fails?
+- Are health checks and monitoring in place?
+
+#### 10. Getting the Most from Claude Code
+This is your unique contribution. Most architecture audits don't evaluate
+the LLM integration layer. You do:
+
+- **Are we using features we should be?** Check Claude Code docs for
+  capabilities the project doesn't leverage: hooks, plugins, agent teams,
+  scheduled tasks, checkpointing, headless mode, etc.
+- **Is our MCP setup optimal?** Are there MCP servers we should add?
+  Are existing ones configured well?
+- **Is the memory system well-structured?** Are memory files focused,
+  current, and non-redundant?
+- **Are subagent patterns right?** When do we use Agent tool vs inline
+  work? Is the taxonomy serving us?
+- **Could hooks replace manual conventions?** If CLAUDE.md says "always
+  run X after Y," that should be a hook, not a hope.
+
+#### 11. Dependency Direction
+Dependencies should point inward (toward core abstractions) not outward
+(toward specific implementations):
+
+- Do components depend on abstractions (interfaces, types) or
+  implementations (specific API endpoints, file paths)?
+- Are there circular dependencies between modules?
+- Could you swap out a layer (different DB, different UI framework)
+  without rebuilding everything?
+
+### Scan Scope
+
+This perspective has the broadest scope -- the whole system:
+
+- `CLAUDE.md` -- Root system guide
+- `**/CLAUDE.md` -- All nested context files
+- `.claude/skills/` -- Skill definitions
+- `.claude/settings*.json` -- Claude Code configuration
+- `.mcp.json` -- MCP server configuration
+- `_context.md` -- Project context (if present)
+- Server/API entry points -- Express, FastAPI, etc.
+- Frontend app structure -- React, Vue, etc.
+- Schema/model definitions
+- Infrastructure config -- Dockerfile, docker-compose, CI/CD
+- Deployment config -- Railway, Vercel, AWS, etc.
+- Claude Code docs (via framework-docs MCP) -- capability reference
+
+## Boundaries
+
+- Code-level quality issues (that's technical-debt's job if present)
+- Framework-specific patterns (handled by framework-specific perspectives)
+- Individual UX issues (that's usability's job if present)
+- Planned features acknowledged in project status docs
+- Early-stage architecture that's intentionally simple
+
+## Calibration Examples
+
+- Root CLAUDE.md has grown to 200+ lines covering system guide, directory
+  structure, workflows, and deployment. Claude Code docs recommend 50-100
+  lines in root with @imports for detail. Which sections should be extracted
+  to nested CLAUDE.md files or .claude/rules/ files?
+
+- CLAUDE.md says "always run validation after modifying X" -- this relies
+  on human memory. Claude Code supports hooks that run automatically on
+  events. A hook could run validation whenever relevant files are modified,
+  making the convention automatic. Would a hook be too aggressive, or
+  could it be scoped correctly?
+
+- The project uses a local SQLite file as both development database and
+  production store. Should these be separated? What happens when two
+  processes write concurrently? Is there a migration story?
+
+- Three npm packages provide overlapping functionality (e.g., two HTTP
+  clients, two date libraries). This is a build-vs-buy debt pattern --
+  the team adopted new tools without removing old ones.

package/templates/skills/perspectives/box-health/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: perspective-box-health
 description: |
-  Box adoption and configuration health analyst. Evaluates whether PIB is
+  Box 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.
@@ -42,7 +42,7 @@ See `_context.md` for shared perspective context.
 You are the **box adoption and configuration health analyst.** Other
 perspectives evaluate the product. Meta-process evaluates whether skills and
 perspectives are doing their jobs well -- prompt quality, calibration, overlap.
-You evaluate something different: whether the PIB infrastructure is configured
+You evaluate something different: whether the CoR infrastructure is configured
 correctly for THIS project. Are the right skills adopted? Are phase files
 customized where they need to be? Is the system growing in useful directions
 or stagnating? Is there dead weight accumulating?
@@ -50,7 +50,7 @@ or stagnating? Is there dead weight accumulating?
 Your unique value is that you prevent two failure modes that pull in opposite
 directions:
 
-- **Under-adoption.** The project installs PIB skeletons but leaves them at
+- **Under-adoption.** The project installs CoR skeletons but leaves them at
   defaults where customization is needed. Phase files sit empty when the
   project clearly has domain-specific concerns those phases should encode.
   Perspectives exist in the template but nobody activated them despite the
@@ -70,7 +70,7 @@ where defaults fall short, and dead weight is actively pruned.
 
 You are NOT evaluating whether skills work well (that's meta-process). You are
 NOT evaluating whether the product is good (that's the domain perspectives).
-You are evaluating whether the *configuration* of the PIB infrastructure fits
+You are evaluating whether the *configuration* of the CoR infrastructure fits
 the *current state* of the project it serves.
 
 ## Activation Signals
@@ -147,7 +147,7 @@ perspectives with consistently zero signal, and grouping mismatches.
 
 Hooks are the highest-compliance enforcement layer. Check:
 
-- **Installation.** Are the hooks from the PIB package present in
+- **Installation.** Are the hooks from the CoR package present in
   `.claude/settings.json`? Compare against what the skeleton provides vs
   what's actually configured.
 - **Telemetry.** If JSONL telemetry is configured, check that it's being
@@ -202,7 +202,7 @@ consolidation, promotion bottlenecks.
 
 ### 6. Configuration Drift
 
-The project evolves. The PIB configuration should evolve with it. Check for
+The project evolves. The CoR configuration should evolve with it. Check for
 drift between the two:
 
 - **`_context.md` freshness.** Compare the shared context file against the
@@ -266,7 +266,7 @@ Do not cross into adjacent perspectives' territory:
   whether it produces useful output, whether its severity levels make sense.
   That's meta-process. You care whether the skill is *installed and used*,
   not whether its output is good.
-- **One-time setup** — initial PIB installation, first-time skeleton
+- **One-time setup** — initial CoR installation, first-time skeleton
   adoption, bootstrapping `_groups.yaml`. That's the onboard skill. You
   evaluate the ongoing health of an already-adopted configuration, not the
   initial adoption process.
@@ -322,7 +322,7 @@ them as zero-signal until they've had a fair chance (3+ cycles).
 **Intentionally minimal configuration:** "Project has only 4 perspectives
 active across 2 groups. The project is a small CLI utility with no database,
 no UI, and no deployment pipeline." — A minimal project should have minimal
-PIB configuration. Absence of perspectives is only a finding when the
+CoR configuration. Absence of perspectives is only a finding when the
 project's complexity warrants them.
 
 ### Severity Anchors

package/templates/skills/perspectives/data-integrity/SKILL.md

@@ -95,7 +95,7 @@ Read your API server (see `_context.md § API / Server`) and check:
   against actual API responses)
 
 #### Step 5: Check Identity Integrity
-If your project uses a stable identity system (fid tags, UUIDs, slugs,
+If your project uses a stable identity system (UUIDs, slugs, semantic IDs,
 or similar), verify:
 
 - Items that should have identity tags but don't
@@ -126,7 +126,7 @@ have internal consistency requirements:
 
 ## Boundaries
 
-- Empty sub-inboxes (that's healthy -- captures are processed)
+- Empty sub-collections or queues (that's healthy -- items are processed)
 - New entities with minimal structure (expected in early stages)
 - Items added today (they're fresh, not stale)
 - Deployment architecture concerns (that's the architecture expert)

package/templates/skills/perspectives/documentation/SKILL.md

@@ -147,11 +147,10 @@ grep -oP '`[^`]+\.(sh|js|ts|tsx|md|yaml|json)`' CLAUDE.md | \
 
 ## Calibration Examples
 
-**Good observation:** "Root CLAUDE.md line 42 lists 'sync/ -- Sync state
-(deployment sync logs)' in the directory structure. The sync/ directory exists
-but is empty -- sync state is no longer tracked in files since the migration.
-Should the sync/ directory be removed and CLAUDE.md updated, or should sync
-state files be created for the current sync mechanism?"
+**Good observation:** "Root CLAUDE.md lists a 'logs/' directory in the
+directory structure, but the directory exists and is empty -- logging was
+migrated to a cloud service. Should the directory be removed and CLAUDE.md
+updated, or should log files be created for the current logging mechanism?"
 
 **Good observation:** "Convention violation: 3 components import a UI library
 directly. CLAUDE.md states all UI imports go through components/ui/index.ts.