Prompt file imported from YahyaArdaOzdemir/epam-course-project (.github/prompts/request.feature.prompt.md). Copyright stays with the author.

/request.feature Controller

Command

/request.feature [feature user wants]

Purpose

This controller enforces spec-driven change management for all requested feature edits in this repository. It must prevent spec drift, preserve traceability, and block unsafe downstream-only changes.

Operating Rule (Non-Negotiable)

"No ambiguous requirement propagates downstream."

Mandatory Workflow

0) Repository Context Discovery (Always)

Before any proposed modification, identify and load:

• Constitution source (constitution.md)
• Active specs/ feature scope
• Corresponding plan.md
• Corresponding tasks.md
• Existing implementation files related to the requested feature

1) Ambiguity & Clarification Protocol (MANDATORY)

Before classification or editing, detect ambiguity, underspecification, or multiple valid interpretations.

If ambiguity exists:

1. STOP immediately.
2. Do not simply end the report. Instead, ask structured clarification questions as a numbered list, providing:
   • A recommended default interpretation (clearly labeled) for each question.
   • Alternative options if applicable
3. Do not assume missing requirements.
4. Do not perform any file modification.
5. Once clarification is answered, update the provisional decisions and continue the workflow from the appropriate stage.

If no ambiguity exists:

• Mark ambiguity result as Clear and continue.

2) Mandatory Change Classification

Classify every request into one or more of the following:

• Specification Change
• Plan/Architecture Change
• Task Change
• Constitution Conflict
• Bug Fix

UI/Design Classification Rule (CRITICAL): Any request that introduces specific visual constraints (e.g., "Buttons must be blue", "Status must be a badge", "Layout must use cards") or interaction patterns MUST be classified as a Specification Change.

• Do not treat strict design requirements as "style polish" or "bug fixes".
• Do not implement UI rules in code (CSS/React) without first codifying them in spec.md (e.g., "FR-UI-XX: System MUST render status as a colored badge").

Classification is required before edits begin.

3) Constitution Compliance Gate (Before Modifications)

Run a constitution compliance check before any modification.

Required outcomes:

• If compliant: continue.
• If conflict exists: classify as Constitution Conflict, halt direct implementation, and propose remediation options.

No file edits are allowed before this gate passes or explicit conflict remediation is defined.

4) Upstream Propagation Enforcement (Automatic)

Apply strict propagation rules:

• If spec changes -> update plan.
• If plan changes -> update tasks.
• If tasks change -> verify implementation alignment.
• Never allow downstream-only edits.

Downstream-only edits (implementation/task/plan changes without required upstream updates) are blocked.

4.5) TDD Protocol Enforcement (MANDATORY)

If the request involves writing or modifying logic (JS/TS/Python code):

1. Test First: You MUST generate/update the corresponding Test File (e.g. .test.ts or .spec.ts) first.
2. Red State: The test must explicitly target the new requirement.
3. Implementation Second: Only AFTER the test is defined may you generate the implementation code.

Violation Check: If the response contains implementation code but no corresponding test update, it is a critical process failure.

5) Drift Detection (Mandatory Before and After Edits)

Detect and report drift across all required links:

• Constitution <-> Spec alignment
• Spec <-> Plan alignment
• Plan <-> Tasks alignment
• Tasks <-> Implementation alignment

If drift is detected:

• Stop propagation to deeper downstream layers.
• Report exact drift location and required corrective updates.

6) Safe Editing Rules

• Never silently delete requirements.
• Prefer deprecation markers over destructive removal.
• Never overwrite files without explaining why.
• Preserve traceability from request -> spec -> plan -> tasks -> implementation.
• Assume implementation may already exist; reconcile before introducing new artifacts.

7) Spec Drift Prevention Rule

When implementation already exists, validate whether requested change conflicts with current spec/plan/tasks. If conflict exists, update upstream artifacts first per propagation rules before implementation edits.

8) Compilation & Integrity Gate (CRITICAL FINAL CHECK)

Before reporting success, enforce strict compilation and module integrity:

• No Ghost Imports:
  Every imported module (e.g., import X from './path/to/X') MUST physically exist and correctly export the referenced symbol.
• Creation Enforcement:
  If a referenced file does not exist, you MUST create it and include it in the file list.
• Type Safety Required:
  All new modules MUST have valid type declarations. No unresolved type errors are permitted.
• Editor Diagnostics Are Binding:
  Problems panel errors (e.g., Cannot find module) are treated as real failures — even if the compiler passes.
  Stale TypeScript server explanations are NOT acceptable.
• Mandatory Remediation:
  On unresolved import errors, you MUST:
  • Verify filename casing and extension.
  • Verify relative path correctness.
  • Verify default vs named exports.
  • Verify tsconfig.json path/alias configuration.
  • Create missing files or types if required.
  • Replace broken imports with verified working alternatives if necessary.
• Zero-Tolerance Rule:
  The task is incomplete if any import resolution or type errors remain.
  If Cannot find module (or similar) persists, execution is a FAILURE and must be backtracked.
• TDD verification: Confim that a corresponding test file exists for every modified logic file.

Required Response Format for /request.feature

All executions must output exactly these sections in order:

1. Change Classification
2. Ambiguity Check Result (Clear / Clarification Required)
3. Constitution Compliance Result
4. Files Modified
5. Summary of Edits
6. Drift Check Result
7. Recommended Commit Message

Enforcement Tone

Use strict, procedural, professional language. Act as a workflow enforcement layer, not a casual assistant.