@sureshdsk/devflow-mcp 3.0.0 → 3.0.1

package/.next/standalone/devflow/specs/autodetect-skill-and-slash-command-installation/design.md

@@ -11,17 +11,20 @@ The design isolates environment-specific logic behind adapters so support can be
 ### Components
 
 1. Installer Orchestrator
+
 - Entry point for install flow.
 - Coordinates `detect -> resolve targets -> install -> summarize`.
 - Aggregates per-environment results and exit status.
 
 2. Environment Detectors
+
 - `ClaudeCodeDetector`
 - `CodexDetector`
 - Each detector determines availability using tool-specific signals (binary presence, expected config directory, or both).
 - Output is normalized into a common `DetectedEnvironment` model.
 
 3. Environment Adapters
+
 - `ClaudeCodeAdapter`
 - `CodexAdapter`
 - Each adapter resolves destination paths for:
@@ -30,6 +33,7 @@ The design isolates environment-specific logic behind adapters so support can be
 - Encapsulates environment-specific path rules and platform handling.
 
 4. Asset Installer
+
 - Copies DevFlow-managed assets (skills and commands) into resolved targets.
 - Uses safe write strategy:
   - create temp file/dir
@@ -38,6 +42,7 @@ The design isolates environment-specific logic behind adapters so support can be
 - Tracks installed/updated/skipped operations.
 
 5. Summary Reporter
+
 - Emits per-environment outcome with:
   - detected status
   - target paths
@@ -65,6 +70,7 @@ The design isolates environment-specific logic behind adapters so support can be
 No persistent database schema changes are required.
 
 In-memory models introduced:
+
 - `DetectedEnvironment`
   - `id` (`claude-code` | `codex`)
   - `version?`
@@ -85,6 +91,7 @@ In-memory models introduced:
 No external network API changes.
 
 CLI/installer behavior changes:
+
 - Existing install command performs auto-detection by default.
 - Optional flags:
   - `--no-autodetect` to disable environment detection and preserve manual behavior.
@@ -112,12 +119,14 @@ CLI/installer behavior changes:
 ## Testing Strategy
 
 1. Unit tests
+
 - Detector tests for present/absent/malformed signals.
 - Adapter path resolution tests across OS path variants.
 - Asset installer idempotency and safe-write tests.
 - Summary reporter formatting and status mapping tests.
 
 2. Integration tests
+
 - Simulated filesystem environments for:
   - Claude Code only
   - Codex only
@@ -127,6 +136,7 @@ CLI/installer behavior changes:
 - Partial failure scenario (one env succeeds, one fails).
 
 3. End-to-end installer tests
+
 - Run installer with fixtures and verify:
   - expected files created/updated
   - unrelated files unchanged
@@ -134,4 +144,5 @@ CLI/installer behavior changes:
   - exit code behavior
 
 4. Regression coverage
+
 - Existing manual install flows remain functional when autodetect disabled or unavailable.

package/.next/standalone/devflow/specs/autodetect-skill-and-slash-command-installation/proposal.md

@@ -9,6 +9,7 @@ DevFlow installation currently requires manual setup steps for AI coding environ
 Add an installation flow that automatically detects supported AI coding environments (Claude Code and Codex) and installs compatible skills and slash commands without requiring manual environment-specific steps.
 
 The installer will:
+
 - Detect which supported tools are present on the host.
 - Determine install targets and paths for each detected tool.
 - Install DevFlow skills and slash commands into the detected environment(s).
@@ -18,6 +19,7 @@ The installer will:
 ## Scope
 
 ### In Scope
+
 - Detection logic for Claude Code and Codex presence.
 - Mapping from detected tool to install locations for skills and slash commands.
 - Automatic installation of DevFlow-provided skills and slash commands.
@@ -25,6 +27,7 @@ The installer will:
 - Safe handling for partial support cases (e.g., only one tool detected).
 
 ### Out of Scope
+
 - Supporting additional AI coding tools beyond Claude Code and Codex.
 - Migration of existing user-customized skills/commands.
 - Cloud-based environment discovery.

package/.next/standalone/devflow/specs/autodetect-skill-and-slash-command-installation/tasks.md

@@ -1,6 +1,7 @@
 # Tasks: Auto-Detect and Install Skills and Slash Commands
 
 ## How To Use This File
+
 - Create one task card per meaningful unit of delivery.
 - Keep tasks dependency-ordered and independently executable where possible.
 - Every task card must include enough context that a new agent can execute it without re-discovery work.
@@ -9,23 +10,28 @@
 ## 1. Delivery Overview
 
 ### 1.1 Objective
+
 Deliver an installation flow that auto-detects Claude Code and Codex, resolves environment-specific install targets, installs DevFlow skills and slash commands idempotently, and reports clear per-environment outcomes with safe failure behavior.
 
 ### 1.2 In-Scope Outcomes
+
 - Automatic detection and install target resolution for Claude Code and Codex.
 - Automatic installation of DevFlow-managed skills and slash commands for each detected environment.
 - Clear summary output and robust failure isolation.
 
 ### 1.3 Non-Goals
+
 - Support for additional AI coding environments beyond Claude Code and Codex.
 - Migration tooling for arbitrary user-managed custom skills/commands.
 
 ### 1.4 Global Constraints
+
 - Preserve existing manual flow via explicit opt-out/override flags.
 - Only modify DevFlow-managed files; never modify unrelated user files.
 - Installer must remain idempotent and safe on repeated runs.
 
 ### 1.5 Shared References
+
 - Proposal: `devflow/specs/autodetect-skill-and-slash-command-installation/proposal.md`
 - Design: `devflow/specs/autodetect-skill-and-slash-command-installation/design.md`
 - Specs: `devflow/specs/autodetect-skill-and-slash-command-installation/specs.md`
@@ -40,6 +46,7 @@ Deliver an installation flow that auto-detects Claude Code and Codex, resolves e
 Inspect existing install pipeline, add environment detection contracts and registry, implement Claude Code and Codex detectors, add unit tests for detection scenarios, run tests, then update task summary and check out.
 
 ### 2.1 Task: Add environment detection and adapter contracts
+
 - [ ] **Status**
 - **Task ID:** `T1`
 - **Owner Type:** `agent`
@@ -53,6 +60,7 @@ Create a shared detector/adapter contract and implement Claude Code and Codex de
 Detection must be environment-specific but consumed by common orchestration logic. This is foundational for all later tasks.
 
 **Scope**
+
 - In scope:
   - Define `DetectedEnvironment` and adapter interfaces.
   - Implement `ClaudeCodeDetector` and `CodexDetector`.
@@ -61,6 +69,7 @@ Detection must be environment-specific but consumed by common orchestration logi
   - Actual file installation writes.
 
 **Implementation Targets**
+
 - Files to create/update:
   - installer detection and adapter modules
   - shared types/contracts for detection results
@@ -69,11 +78,13 @@ Detection must be environment-specific but consumed by common orchestration logi
   - environment identifier enum/string union
 
 **Execution Steps**
+
 1. Define detector result and environment ID contracts.
 2. Implement tool-specific detection logic for Claude Code and Codex.
 3. Add registry wiring and unit tests for detection permutations.
 
 **Validation**
+
 - Automated tests to add/update:
   - detection unit test suite covering present/absent/both/none
 - Commands to run:
@@ -83,10 +94,12 @@ Detection must be environment-specific but consumed by common orchestration logi
   - verify detector debug output is understandable in verbose mode
 
 **Acceptance Criteria**
+
 - Detection returns correct environment set for all four core scenarios.
 - Contracts are stable and reusable by orchestration layer.
 
 **Risks and Mitigations**
+
 - Risk: false positives from weak detection signals.
   - Mitigation: require at least one strong signal or multi-signal confirmation per environment.
 
@@ -94,16 +107,18 @@ Detection must be environment-specific but consumed by common orchestration logi
 Provide detector contract docs and examples so next task can integrate target resolution without re-discovery.
 
 **Task Summary**
+
 - Completed: no
 - What was done: N/A
 - Files changed: N/A
 - Issues encountered: N/A
 - Follow-ups: N/A
-**Execution Plan**
+  **Execution Plan**
 
 Refactor install-skills to use adapter-resolved targets with safe write semantics, enforce DevFlow-managed ownership checks, isolate failures per environment/asset, and expand tests for no-op re-run and partial failure scenarios before checking out.
 
 ### 2.2 Task: Implement install target resolution and idempotent asset installer
+
 - [ ] **Status**
 - **Task ID:** `T2`
 - **Owner Type:** `agent`
@@ -117,6 +132,7 @@ Resolve per-environment install paths and implement safe, idempotent installatio
 Path resolution and write behavior are environment-dependent and must be failure-isolated per environment.
 
 **Scope**
+
 - In scope:
   - Implement `ClaudeCodeAdapter` and `CodexAdapter` path resolution.
   - Build asset installer with safe writes and ownership checks.
@@ -125,6 +141,7 @@ Path resolution and write behavior are environment-dependent and must be failure
   - CLI flags and final summary UX polish.
 
 **Implementation Targets**
+
 - Files to create/update:
   - adapter implementations
   - install/write utility modules
@@ -134,11 +151,13 @@ Path resolution and write behavior are environment-dependent and must be failure
   - install operation result model
 
 **Execution Steps**
+
 1. Implement adapter path resolution for both environments.
 2. Add idempotent copy/update logic for skills and slash commands.
 3. Add tests for permission errors, partial failures, and no-op re-run behavior.
 
 **Validation**
+
 - Automated tests to add/update:
   - adapter resolution tests
   - installer idempotency and failure isolation tests
@@ -149,11 +168,13 @@ Path resolution and write behavior are environment-dependent and must be failure
   - run installer twice against fixture dirs and confirm second run is no-op
 
 **Acceptance Criteria**
+
 - Installer writes expected assets for each resolved environment.
 - Re-running installer does not duplicate files and only updates changed DevFlow-managed assets.
 - Failure in one environment does not prevent install in another.
 
 **Risks and Mitigations**
+
 - Risk: accidental overwrite of user-managed files.
   - Mitigation: strict ownership markers and deny-write for unmanaged files.
 
@@ -161,16 +182,18 @@ Path resolution and write behavior are environment-dependent and must be failure
 Document adapter path assumptions by OS so CLI integration task can surface helpful diagnostics.
 
 **Task Summary**
+
 - Completed: no
 - What was done: N/A
 - Files changed: N/A
 - Issues encountered: N/A
 - Follow-ups: N/A
-**Execution Plan**
+  **Execution Plan**
 
 Integrate autodetect pipeline into install-skills and devflow CLI, add --no-autodetect/--only/--dry-run flags, include per-environment summary output, add tests for flag behavior and dry-run, update task summary, then check out.
 
 ### 2.3 Task: Integrate pipeline into installer CLI and add summary reporting
+
 - [ ] **Status**
 - **Task ID:** `T3`
 - **Owner Type:** `agent`
@@ -184,6 +207,7 @@ Connect detect/resolve/install pipeline to the installer command and provide cle
 This task makes the behavior user-visible and keeps backward compatibility for manual flow via flags.
 
 **Scope**
+
 - In scope:
   - Wire orchestrator into install command.
   - Add `--no-autodetect`, `--only=<env>`, and `--dry-run` (or equivalent naming per CLI conventions).
@@ -192,6 +216,7 @@ This task makes the behavior user-visible and keeps backward compatibility for m
   - New environment support beyond Claude Code/Codex.
 
 **Implementation Targets**
+
 - Files to create/update:
   - installer CLI entrypoint and option parsing
   - orchestrator module
@@ -200,11 +225,13 @@ This task makes the behavior user-visible and keeps backward compatibility for m
   - install command behavior and flags
 
 **Execution Steps**
+
 1. Add orchestration pipeline invocation to install command.
 2. Implement flags and execution branches (autodetect/default, restricted env, dry-run).
 3. Add integration/e2e tests for summary output and exit code behavior.
 
 **Validation**
+
 - Automated tests to add/update:
   - CLI integration tests for core scenarios and flags
 - Commands to run:
@@ -214,11 +241,13 @@ This task makes the behavior user-visible and keeps backward compatibility for m
   - run installer in fixture setups for Claude-only, Codex-only, both, and none
 
 **Acceptance Criteria**
+
 - Default install auto-detects and installs for supported detected environments.
 - Summary output clearly reports installed/skipped/failed per environment with reasons.
 - Flags work as documented and preserve manual behavior when requested.
 
 **Risks and Mitigations**
+
 - Risk: confusing CLI output in partial-failure cases.
   - Mitigation: structured per-environment summary with explicit reason and suggested remediation.
 
@@ -226,6 +255,7 @@ This task makes the behavior user-visible and keeps backward compatibility for m
 Include before/after CLI output examples in docs for release notes and support.
 
 **Task Summary**
+
 - Completed: no
 - What was done: N/A
 - Files changed: N/A
@@ -233,12 +263,14 @@ Include before/after CLI output examples in docs for release notes and support.
 - Follow-ups: N/A
 
 ## 3. Cross-Task Verification
+
 - [ ] End-to-end behavior matches `specs.md` requirements and scenarios.
 - [ ] All affected tests are updated and passing.
 - [ ] User-facing docs and command help are updated where behavior changed.
 - [ ] Rollback path is documented for risky changes.
 
 ## 4. Completion Gate
+
 - [ ] All task cards are checked complete.
 - [ ] Spec validation command passes for `autodetect-skill-and-slash-command-installation`.
 - [ ] Implementation summary and follow-up items are recorded in handoff notes.

package/.next/standalone/devflow/specs/precommit/.approvals.json

@@ -0,0 +1,26 @@
+{
+  "version": 1,
+  "artifacts": {
+    "proposal": {
+      "state": "approved",
+      "approvedAt": "2026-02-27T12:20:51.946Z",
+      "contentHash": "4c009bda20fed6264ed0b3db42790f875c54889b5f64de30f0592402ffb150a1",
+      "approvedBy": "human"
+    },
+    "specs": {
+      "state": "approved",
+      "approvedAt": "2026-02-27T12:47:30.347Z",
+      "contentHash": "daab8a3eb6cdd62994319eb3924ccc4a3c6abba1fe172baf65deb77f0898b673",
+      "approvedBy": "human"
+    },
+    "design": {
+      "state": "approved",
+      "approvedAt": "2026-02-27T12:47:30.355Z",
+      "contentHash": "a99715ba724aebf55aee18340effd33a321c041859d9d50f9d5c313be5b3d882",
+      "approvedBy": "human"
+    },
+    "tasks": {
+      "state": "draft"
+    }
+  }
+}

package/.next/standalone/devflow/specs/precommit/.meta.json

@@ -0,0 +1,7 @@
+{
+  "name": "precommit",
+  "title": "Setup automatic linting formatting on git commit",
+  "projectId": "6e86100c-1ce0-4177-abba-f74082db5f05",
+  "schema": "spec-driven",
+  "createdAt": "2026-02-27T12:13:06.878Z"
+}

package/.next/standalone/devflow/specs/precommit/design.md

@@ -0,0 +1,105 @@
+# Design: Setup automatic linting & formatting on git commit
+
+## Overview
+
+Add a pre-commit hook pipeline using husky (v9) and lint-staged (v15) that runs ESLint and Prettier on staged files. No architecture or data model changes — this is purely a developer tooling addition.
+
+## Architecture
+
+```mermaid
+flowchart TD
+    A[git commit] --> B[.husky/pre-commit]
+    B --> C[npx lint-staged]
+    C --> D{File type?}
+    D -->|*.ts, *.tsx| E[eslint --fix]
+    E --> F[prettier --write]
+    D -->|*.js, *.json, *.css, *.md| F
+    D -->|other files| G[skip]
+    F --> H{Errors?}
+    H -->|No| I[Re-stage fixed files]
+    I --> J[Commit succeeds]
+    H -->|Yes| K[Commit blocked]
+    G --> J
+```
+
+All configuration lives in the project root:
+
+- `.husky/pre-commit` — shell script that runs `npx lint-staged`
+- `package.json` — `lint-staged` config block and `prepare` script
+- `.prettierrc` — Prettier options
+- `.prettierignore` — files/dirs to skip (node_modules, .next, dist)
+
+## Data Model Changes
+
+None.
+
+## API Changes
+
+None.
+
+## Implementation Notes
+
+### Package versions
+
+- `husky@^9` — uses the simplified `husky init` setup (no `husky install`)
+- `lint-staged@^15` — latest stable
+- `prettier@^3` — latest stable
+
+### package.json changes
+
+Add to `scripts`:
+
+```json
+"prepare": "husky"
+```
+
+The existing `postinstall` script is unaffected — `prepare` runs after `install` and before `prepublishOnly`.
+
+Add `lint-staged` config block:
+
+```json
+"lint-staged": {
+  "*.{ts,tsx}": ["eslint --fix", "prettier --write"],
+  "*.{js,json,css,md}": ["prettier --write"]
+}
+```
+
+### .prettierrc
+
+```json
+{
+  "semi": true,
+  "singleQuote": true,
+  "trailingComma": "all",
+  "tabWidth": 2,
+  "printWidth": 100
+}
+```
+
+### .prettierignore
+
+```
+node_modules
+.next
+dist
+drizzle
+```
+
+### Husky setup
+
+Run `npx husky init` which creates `.husky/pre-commit`. Replace its contents with:
+
+```sh
+npx lint-staged
+```
+
+### Baseline formatting commit
+
+After setup, run `npx prettier --write .` across the codebase and commit as a single formatting commit before the hook is active for other developers.
+
+## Testing Strategy
+
+- **Manual**: Stage a file with a formatting issue, run `git commit`, verify it gets auto-fixed
+- **Manual**: Stage a file with a non-fixable ESLint error, run `git commit`, verify it's blocked
+- **Manual**: Run `npm install` in a fresh clone, verify `.husky/` hooks are installed
+- **CI**: No changes needed — CI doesn't use git hooks

package/.next/standalone/devflow/specs/precommit/proposal.md

@@ -0,0 +1,43 @@
+# Proposal: Setup automatic linting & formatting on git commit
+
+## Problem Statement
+
+There is no automated code quality gate on commit. Developers (and AI agents) can commit code with lint errors, inconsistent formatting, or type issues. This leads to noisy diffs, broken CI, and wasted review cycles.
+
+## Proposed Solution
+
+Add **lint-staged** + **husky** to run ESLint and Prettier automatically on staged files during `git commit`. This ensures every commit passes linting and formatting checks before it lands.
+
+- **Husky** — manages the git `pre-commit` hook
+- **lint-staged** — runs linters only on staged files for speed
+- **Prettier** — formats `.ts`, `.tsx`, `.js`, `.json`, `.css`, `.md` files
+- ESLint (already installed) — lints `.ts` and `.tsx` files
+
+## Scope
+
+### In Scope
+
+- Install husky, lint-staged, and prettier as devDependencies
+- Configure husky pre-commit hook to run lint-staged
+- Configure lint-staged to run `eslint --fix` on `.ts/.tsx` files and `prettier --write` on all supported files
+- Add a `.prettierrc` with sensible defaults (single quotes, trailing commas, 2-space indent)
+- Add `prepare` script (`husky`) to package.json so hooks install automatically on `npm install`
+
+### Out of Scope
+
+- CI pipeline changes
+- Commit message linting (commitlint)
+- Pre-push hooks (e.g. running tests or typecheck)
+- Changing existing ESLint rules
+
+## Success Criteria
+
+- Running `git commit` on files with formatting issues auto-fixes them before committing
+- Running `git commit` on files with lint errors blocks the commit with a clear error message
+- Hooks install automatically when a new contributor runs `npm install`
+
+## Risks & Assumptions
+
+- **Assumption**: The team is fine with Prettier's opinionated defaults; first commit may touch many files if existing code doesn't match
+- **Risk**: The `postinstall` script already exists — the `prepare` script for husky must coexist without conflict
+- **Mitigation**: Run Prettier on the full codebase in a single formatting commit before enabling the hook, to avoid noisy diffs on subsequent commits

package/.next/standalone/devflow/specs/precommit/specs.md

@@ -0,0 +1,89 @@
+# Specifications: Setup automatic linting & formatting on git commit
+
+## Overview
+
+This spec defines the requirements for integrating pre-commit hooks that automatically lint and format staged files before each git commit.
+
+### Requirement: Husky Git Hook Installation
+
+**SHALL** install husky and configure it to run a pre-commit hook automatically when contributors run `npm install`.
+
+#### Scenario: Fresh clone and install
+
+**Given** a developer clones the repository for the first time
+**When** they run `npm install`
+**Then** husky installs git hooks into `.husky/` and the pre-commit hook is active
+
+#### Scenario: CI environment
+
+**Given** the project is installed in a CI environment where `CI=true`
+**When** `npm install` runs
+**Then** husky skips hook installation gracefully (no errors)
+
+### Requirement: Lint-Staged Configuration
+
+**SHALL** configure lint-staged to run the appropriate tool on each staged file type.
+
+#### Scenario: TypeScript/TSX files staged
+
+**Given** a developer stages `.ts` or `.tsx` files
+**When** they run `git commit`
+**Then** lint-staged runs `eslint --fix` followed by `prettier --write` on those files
+
+#### Scenario: Non-TypeScript files staged
+
+**Given** a developer stages `.json`, `.css`, `.md`, or `.js` files
+**When** they run `git commit`
+**Then** lint-staged runs `prettier --write` on those files
+
+#### Scenario: No matching files staged
+
+**Given** a developer stages only files not matched by lint-staged (e.g. images, `.gitignore`)
+**When** they run `git commit`
+**Then** the commit proceeds without running any linters
+
+### Requirement: ESLint Auto-Fix on Commit
+
+**SHALL** run `eslint --fix` on staged TypeScript files to auto-fix resolvable issues.
+
+#### Scenario: Auto-fixable lint error
+
+**Given** a staged `.ts` file has an auto-fixable ESLint error (e.g. unused import)
+**When** the pre-commit hook runs
+**Then** ESLint fixes the issue, the fixed file is re-staged, and the commit succeeds
+
+#### Scenario: Non-fixable lint error
+
+**Given** a staged `.ts` file has a lint error that cannot be auto-fixed
+**When** the pre-commit hook runs
+**Then** the commit is blocked and the error is printed to the terminal
+
+### Requirement: Prettier Formatting on Commit
+
+**SHALL** run `prettier --write` on staged files to enforce consistent formatting.
+
+#### Scenario: Unformatted file
+
+**Given** a staged file has inconsistent formatting (wrong indentation, missing trailing comma)
+**When** the pre-commit hook runs
+**Then** Prettier reformats the file, the formatted file is re-staged, and the commit succeeds
+
+### Requirement: Prettier Configuration
+
+**SHALL** provide a `.prettierrc` configuration file with project defaults.
+
+#### Scenario: Prettier config is respected
+
+**Given** a `.prettierrc` file exists in the project root
+**When** Prettier runs on any file
+**Then** it uses the settings from `.prettierrc` (single quotes, trailing commas, 2-space indent, 100 char print width)
+
+### Requirement: Baseline Formatting Commit
+
+**SHALL** run Prettier on the entire codebase in a single commit before enabling the hook, to avoid noisy diffs in subsequent commits.
+
+#### Scenario: Initial formatting pass
+
+**Given** the pre-commit hook setup is complete
+**When** Prettier is run across the full codebase
+**Then** all supported files are formatted and committed in a single "chore: format codebase" commit