@sureshdsk/devflow-mcp 3.0.0 → 3.0.1

package/.next/standalone/devflow/specs/add-default-schema-template-selection/tasks.md

@@ -1,235 +0,0 @@
-# Tasks: Add Default Schema Template Selection and Team-Oriented Templates
-
-## 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.
-- Replace all placeholders before implementation starts.
-
-## 1. Delivery Overview
-
-### 1.1 Objective
-Deliver four built-in schema templates (frontend, backend, data engineering, devops), add schema selection to `devflow init`, persist the selected default per project, and ensure new specs use that default while preserving custom template compatibility.
-
-### 1.2 In-Scope Outcomes
-- Built-in template registry and assets for four team-oriented defaults.
-- Interactive and non-interactive `devflow init` schema selection behavior.
-- Project default schema persistence and spec-creation integration.
-
-### 1.3 Non-Goals
-- Auto-migrating existing specs to new template structures.
-- Template marketplace/download support.
-
-### 1.4 Global Constraints
-- Existing projects and custom templates must remain backward compatible.
-- Selection behavior must be deterministic in non-interactive environments.
-
-### 1.5 Shared References
-- Proposal: `devflow/specs/add-default-schema-template-selection/proposal.md`
-- Design: `devflow/specs/add-default-schema-template-selection/design.md`
-- Specs: `devflow/specs/add-default-schema-template-selection/specs.md`
-- Additional docs/code:
-  - `scripts/init-db.js`
-  - `src/lib/schema.ts`
-
-## 2. Task Cards
-
-**Execution Plan**
-
-Inspect current schema template layout and loader logic, add four built-in template sets and metadata IDs, extend registry/discovery to include built-ins and custom templates with conflict validation, add unit tests, run targeted tests, update task summary, and check out.
-
-### 2.1 Task: Add built-in schema template assets and registry support
-- [ ] **Status**
-- **Task ID:** `T1`
-- **Owner Type:** `agent`
-- **Priority:** `P0`
-- **Depends On:** `none`
-
-**Goal**
-Introduce four built-in schema templates and expose them through a registry/discovery mechanism used by init and spec creation flows.
-
-**Context**
-Template assets and IDs are the foundation for selection and persistence behavior. IDs must be stable and validated.
-
-**Scope**
-- In scope:
-  - Add built-in template assets for `frontend-product`, `backend-api`, `data-engineering`, `devops-platform`.
-  - Implement template registry listing built-in plus custom templates.
-  - Add validation for template ID conflicts and unknown IDs.
-- Out of scope:
-  - CLI prompt and persistence flow.
-
-**Implementation Targets**
-- Files to create/update:
-  - schema template directories/files under `src/schemas/`
-  - schema/template registry loader in `src/lib/schema.ts` (or equivalent)
-- Public interfaces or contracts affected:
-  - template registry/listing functions
-  - template metadata shape
-
-**Execution Steps**
-1. Add four built-in template definitions and artifact templates.
-2. Update registry loader to return built-ins and discovered custom templates.
-3. Add unit tests for registry contents, conflict handling, and lookup behavior.
-
-**Validation**
-- Automated tests to add/update:
-  - schema registry unit tests
-- Commands to run:
-  - project test command for schema library/tests
-  - lint/typecheck command
-- Manual checks:
-  - verify registry output includes all four built-ins with expected IDs
-
-**Acceptance Criteria**
-- Registry reliably exposes all four built-in templates.
-- Unknown/conflicting IDs produce actionable errors.
-
-**Risks and Mitigations**
-- Risk: ID collisions with custom templates.
-  - Mitigation: fail fast with explicit conflict message and resolution guidance.
-
-**Handoff Notes**
-Document final template IDs and metadata contract for init flow integration.
-
-**Task Summary**
-- Completed: no
-- What was done: N/A
-- Files changed: N/A
-- Issues encountered: N/A
-- Follow-ups: N/A
-**Execution Plan**
-
-Inspect current init flow and project metadata persistence paths, add schema selection strategy for init (explicit flag, existing default, prompt/fallback), persist default schema at project level, add tests for explicit and non-interactive behavior, update task summary, and check out.
-
-### 2.2 Task: Implement init-time schema selection and default persistence
-- [ ] **Status**
-- **Task ID:** `T2`
-- **Owner Type:** `agent`
-- **Priority:** `P0`
-- **Depends On:** `T1`
-
-**Goal**
-Add schema template selection during `devflow init`, support non-interactive behavior, and persist project default schema.
-
-**Context**
-Selection logic must be precedence-driven and deterministic: explicit flag > existing default > interactive prompt > documented fallback/error.
-
-**Scope**
-- In scope:
-  - Add init selection prompt and option parsing.
-  - Add `--schema <id>` handling for non-interactive/explicit selection.
-  - Persist selected default schema in project config/metadata.
-- Out of scope:
-  - Spec-creation default usage integration.
-
-**Implementation Targets**
-- Files to create/update:
-  - `bin/devflow.js` init command logic
-  - init orchestration scripts (`scripts/init-db.js` and related config persistence code)
-- Public interfaces or contracts affected:
-  - init CLI options/help output
-  - project metadata schema/default field
-
-**Execution Steps**
-1. Add schema selection strategy and prompt flow to `devflow init`.
-2. Implement persistence of selected/default schema ID.
-3. Add tests for interactive path (mocked), explicit flag path, and non-interactive fallback behavior.
-
-**Validation**
-- Automated tests to add/update:
-  - init flow tests for schema selection and persistence
-- Commands to run:
-  - relevant test commands
-  - CLI help command
-- Manual checks:
-  - run `devflow init` interactively and verify selected template is confirmed in output
-
-**Acceptance Criteria**
-- `devflow init` can set default schema through prompt or explicit flag.
-- Non-interactive behavior is deterministic and documented.
-
-**Risks and Mitigations**
-- Risk: init prompts break automation scripts.
-  - Mitigation: explicit `--schema` non-interactive path and clear fallback errors.
-
-**Handoff Notes**
-Provide persisted config key and location details for spec creation integration.
-
-**Task Summary**
-- Completed: no
-- What was done: N/A
-- Files changed: N/A
-- Issues encountered: N/A
-- Follow-ups: N/A
-### 2.3 Task: Apply project default schema to spec creation and update docs
-- [ ] **Status**
-- **Task ID:** `T3`
-- **Owner Type:** `agent`
-- **Priority:** `P1`
-- **Depends On:** `T2`
-
-**Goal**
-Ensure spec creation uses project default schema by default, preserving explicit override precedence, and update user-facing docs/help.
-
-**Context**
-This task closes the loop from template selection to runtime behavior in spec workflows.
-
-**Scope**
-- In scope:
-  - Integrate default schema resolution into spec creation flow.
-  - Preserve explicit schema override precedence.
-  - Update docs/help with template IDs and init usage examples.
-- Out of scope:
-  - UI redesign beyond required messaging updates.
-
-**Implementation Targets**
-- Files to create/update:
-  - spec creation logic (e.g., `src/lib/specs.ts`, API routes)
-  - docs/help text (`README.md`, CLI help output)
-- Public interfaces or contracts affected:
-  - spec creation default schema behavior
-
-**Execution Steps**
-1. Read project default schema when creating new specs.
-2. Keep explicit per-spec schema override as highest precedence.
-3. Add regression tests and update documentation/examples.
-
-**Validation**
-- Automated tests to add/update:
-  - spec creation tests for default/override behavior
-- Commands to run:
-  - full relevant test suite
-  - lint/typecheck command
-- Manual checks:
-  - create specs with and without schema override and verify resolved templates
-
-**Acceptance Criteria**
-- New specs use project default template when no override is given.
-- Explicit override still selects the requested template.
-- Docs clearly explain template selection and custom-template compatibility.
-
-**Risks and Mitigations**
-- Risk: regression in existing spec creation defaults.
-  - Mitigation: add regression tests for legacy/no-default paths.
-
-**Handoff Notes**
-Capture any migration or release-note caveats if defaults impact existing onboarding behavior.
-
-**Task Summary**
-- Completed: no
-- What was done: N/A
-- Files changed: N/A
-- Issues encountered: N/A
-- 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 `add-default-schema-template-selection`.
-- [ ] Implementation summary and follow-up items are recorded in handoff notes.

package/.next/standalone/devflow/specs/test-no-project/.approvals.json

@@ -1,17 +0,0 @@
-{
-  "version": 1,
-  "artifacts": {
-    "proposal": {
-      "state": "draft"
-    },
-    "specs": {
-      "state": "draft"
-    },
-    "design": {
-      "state": "draft"
-    },
-    "tasks": {
-      "state": "draft"
-    }
-  }
-}

package/.next/standalone/devflow/specs/test-no-project/.meta.json

@@ -1,6 +0,0 @@
-{
-  "name": "test-no-project",
-  "title": "Should fail",
-  "schema": "spec-driven",
-  "createdAt": "2026-02-24T07:54:48.589Z"
-}

package/.next/standalone/devflow/specs/ui-cleanup/.approvals.json

@@ -1,29 +0,0 @@
-{
-  "version": 1,
-  "artifacts": {
-    "proposal": {
-      "state": "approved",
-      "approvedAt": "2026-02-23T16:05:18.545Z",
-      "contentHash": "1db474c909255286bfcc0c8d3b794472ae9a9f8a3183e5fa5c1b13c36b581f90",
-      "approvedBy": "human"
-    },
-    "specs": {
-      "state": "approved",
-      "approvedAt": "2026-02-23T16:08:36.862Z",
-      "contentHash": "0094b2e2327556f9a97ed64528b2ef383e92fd873681637572e3c446d65c03e5",
-      "approvedBy": "human"
-    },
-    "design": {
-      "state": "approved",
-      "approvedAt": "2026-02-23T16:09:50.272Z",
-      "contentHash": "c0f39256b0bde4a444df47388c3961938d16e85f66b59cad1ccedcb082345dc8",
-      "approvedBy": "human"
-    },
-    "tasks": {
-      "state": "approved",
-      "approvedAt": "2026-02-23T16:15:18.599Z",
-      "contentHash": "10e034a7dc945c72080bd2012f37a458a707f0b59abf7115ed29a2393641ca80",
-      "approvedBy": "human"
-    }
-  }
-}

package/.next/standalone/devflow/specs/ui-cleanup/.meta.json

@@ -1,6 +0,0 @@
-{
-  "name": "ui-cleanup",
-  "title": "UI Cleanup",
-  "schema": "spec-driven",
-  "createdAt": "2026-02-23T16:01:37.419Z"
-}

package/.next/standalone/devflow/specs/ui-cleanup/design.md

@@ -1,49 +0,0 @@
-# Design: UI Cleanup
-
-## Overview
-
-This change removes manual project/task creation paths from user-accessible UI and API layers while preserving agent-driven creation flows. The implementation is subtractive: remove controls, remove (or hard-disable) direct-create endpoints, and clean related references.
-
-## Architecture
-
-- Frontend: remove `Create Project` and `Create Task` action controls from relevant screens/components.
-- Frontend state/actions: remove client calls tied to direct-create endpoints and any UI wiring for those actions.
-- Backend/API: remove route handlers (or return explicit rejection) for direct project/task creation endpoints exposed for manual usage.
-- Agent workflow boundary: keep agent creation mechanisms intact through existing agent tool routes/services.
-
-Interaction after change:
-- User UI no longer provides create-project/task actions.
-- Client cannot call removed manual create endpoints through existing UI flows.
-- Agent workflows continue to create projects/tasks through approved internal path.
-
-## Data Model Changes
-
-No database schema changes are required.
-
-## API Changes
-
-- Remove or disable direct project creation endpoint currently used by manual UI creation flow.
-- Remove or disable direct task creation endpoint currently used by manual UI creation flow.
-- If endpoints are disabled instead of deleted, return a clear non-success response (for example, 404 or 403 based on service policy) and document behavior.
-
-## Implementation Notes
-
-- Remove all visible entry points, including toolbar buttons, empty-state CTAs, and context-menu actions.
-- Remove dead code paths after button/API removal (hooks, action creators, service methods, tests referencing old manual flow).
-- Ensure no broken navigation or dangling click handlers remain.
-- Preserve any internal/agent-only service paths used by MCP/agent workflows.
-- If external clients depend on removed endpoints, note this as a breaking change in release notes/changelog.
-
-## Testing Strategy
-
-- UI tests:
-  - Verify projects UI renders without `Create Project` action.
-  - Verify tasks UI renders without `Create Task` action.
-  - Verify layouts remain stable after control removal.
-- API tests:
-  - Verify former direct-create project route is unavailable/rejected.
-  - Verify former direct-create task route is unavailable/rejected.
-- Integration tests:
-  - Verify agent-driven project/task creation still succeeds.
-- Regression checks:
-  - Search for stale references to removed create actions/routes and confirm none remain in active code paths.

package/.next/standalone/devflow/specs/ui-cleanup/proposal.md

@@ -1,34 +0,0 @@
-# Proposal: UI Cleanup
-
-## Problem Statement
-
-The UI currently exposes `Create Project` and `Create Task` actions, and corresponding API endpoints are still available for manual creation flows that should be restricted to agent-only operations.
-
-## Proposed Solution
-
-Remove `Create Project` and `Create Task` entry points from the UI and remove the related public API endpoints for direct project/task creation. Creation will remain available only through agent-driven workflows.
-
-## Scope
-
-### In Scope
-- Remove `Create Project` button from UI surfaces where it is currently shown.
-- Remove `Create Task` button from UI surfaces where it is currently shown.
-- Remove relevant API endpoints for direct project/task creation.
-- Ensure UI states and layout remain clean after button removal.
-
-### Out of Scope
-- Changes to core agent-side creation workflows.
-- Broader UI restyling unrelated to these controls/endpoints.
-
-## Success Criteria
-
-- `Create Project` is no longer visible in the UI.
-- `Create Task` is no longer visible in the UI.
-- Direct create project/task API endpoints are removed or disabled.
-- No broken layouts or dead UI references remain where buttons were removed.
-
-## Risks & Assumptions
-
-- Risk: Hidden alternate UI entry points might still expose creation actions.
-- Risk: External consumers may rely on removed create endpoints.
-- Assumption: Agent workflows already support all required project/task creation use cases.

package/.next/standalone/devflow/specs/ui-cleanup/specs.md

@@ -1,55 +0,0 @@
-# Specifications: UI Cleanup
-
-## Overview
-
-This spec removes manual project/task creation capabilities from user-facing surfaces. The UI must no longer expose creation controls, and direct API routes for creating projects/tasks must be removed or disabled. Project/task creation is restricted to agent workflows.
-
-### Requirement: Remove Project Creation UI Entry Point
-
-**SHALL** remove any user-facing `Create Project` control from the application UI.
-
-#### Scenario: Projects page controls
-
-**Given** a user opens the projects interface
-**When** the page renders available actions
-**Then** no `Create Project` button or equivalent create-project trigger is visible
-
-### Requirement: Remove Task Creation UI Entry Point
-
-**SHALL** remove any user-facing `Create Task` control from the application UI.
-
-#### Scenario: Tasks page controls
-
-**Given** a user opens the tasks interface
-**When** the page renders available actions
-**Then** no `Create Task` button or equivalent create-task trigger is visible
-
-### Requirement: Remove Direct Create Project API Endpoint
-
-**SHALL** remove or disable the direct API endpoint used for manual project creation.
-
-#### Scenario: Direct project creation request
-
-**Given** a client attempts to call the previous project-creation API route
-**When** the request is processed
-**Then** the route is unavailable or rejects the request per implementation policy
-
-### Requirement: Remove Direct Create Task API Endpoint
-
-**SHALL** remove or disable the direct API endpoint used for manual task creation.
-
-#### Scenario: Direct task creation request
-
-**Given** a client attempts to call the previous task-creation API route
-**When** the request is processed
-**Then** the route is unavailable or rejects the request per implementation policy
-
-### Requirement: Preserve Agent-Driven Creation Workflows
-
-**SHALL** keep agent-driven project/task creation workflows functional.
-
-#### Scenario: Agent creates project/task
-
-**Given** an agent workflow invokes supported creation tools
-**When** the workflow executes creation operations
-**Then** project and task creation completes successfully without using removed UI controls or removed direct-create endpoints

package/.next/standalone/devflow/specs/ui-cleanup/tasks.md

@@ -1,28 +0,0 @@
-# Tasks: UI Cleanup
-
-## Task: Remove create project/task controls from UI
-Priority: high
-Remove all user-facing `Create Project` and `Create Task` controls from projects/tasks screens, including toolbar buttons, empty-state CTAs, and menu entries.
-
-Acceptance notes:
-- UI no longer renders create controls for projects or tasks.
-- Related click handlers, hooks, and dead references are removed.
-- Layouts remain stable after control removal.
-
-## Task: Remove direct manual create API endpoints
-Priority: high
-Remove or disable direct API endpoints used for manual project and task creation from the UI-facing API surface.
-
-Acceptance notes:
-- Former direct create-project route is unavailable or explicitly rejected.
-- Former direct create-task route is unavailable or explicitly rejected.
-- Route registration and API tests are updated accordingly.
-
-## Task: Verify agent-driven project/task creation still works
-Priority: high
-Validate that MCP/agent workflows can still create projects and tasks after UI controls and manual endpoints are removed.
-
-Acceptance notes:
-- Agent workflow successfully creates a project.
-- Agent workflow successfully creates a task.
-- Regression tests cover agent creation path independent of removed manual endpoints.