feat(FN-1559): enforce feature status invariants at API boundary
- Guard PATCH /api/missions/features/:featureId to reject status transitions to execution states (triaged, in-progress, done, blocked) when feature has no taskId - 'defined' status remains always allowed (initial state) - Non-status field updates (title, description) are unaffected - Add 6 new tests covering guard behavior and edge cases - All 147 mission-e2e tests passing
This commit is contained in:
@@ -36,7 +36,9 @@ export type PromptKey =
|
||||
| "reviewer-verdict"
|
||||
| "merger-conflicts"
|
||||
| "agent-generation-system"
|
||||
| "workflow-step-refine";
|
||||
| "workflow-step-refine"
|
||||
| "planning-system"
|
||||
| "subtask-breakdown-system";
|
||||
|
||||
/**
|
||||
* Metadata describing a prompt key including its purpose and default content.
|
||||
@@ -251,6 +253,86 @@ The prompt should:
|
||||
|
||||
Output ONLY the prompt text (no markdown, no explanations).`,
|
||||
},
|
||||
"planning-system": {
|
||||
key: "planning-system",
|
||||
name: "Planning System",
|
||||
roles: ["triage"],
|
||||
description: "System prompt for the AI planning assistant that guides users through task definition",
|
||||
defaultContent: `You are a planning assistant for the fn task board system.
|
||||
|
||||
Your job: help users transform vague, high-level ideas into well-defined, actionable tasks.
|
||||
|
||||
## Conversation Flow
|
||||
1. User provides a high-level plan (e.g., "Build a user auth system")
|
||||
2. You ask clarifying questions to understand scope, requirements, and constraints
|
||||
3. You present UI-friendly selection options when appropriate
|
||||
4. Once you have enough information, generate a structured summary
|
||||
|
||||
## Question Types to Use
|
||||
- "text": Open-ended follow-up questions for detailed input
|
||||
- "single_select": When user must choose one option (e.g., tech stack preference)
|
||||
- "multi_select": When multiple options can apply (e.g., features to include)
|
||||
- "confirm": Yes/No questions for quick decisions
|
||||
|
||||
## Guidelines
|
||||
- Ask 3-7 questions depending on complexity
|
||||
- Start broad, then narrow down specifics
|
||||
- Suggest sensible defaults based on project context
|
||||
- Keep questions focused and actionable
|
||||
- When asking about file scope, reference actual project structure
|
||||
|
||||
## Summary Generation
|
||||
When ready to complete, generate:
|
||||
- A concise but descriptive title (max 80 chars)
|
||||
- A detailed description with context gathered
|
||||
- Size estimate (S/M/L) based on scope
|
||||
- Any suggested dependencies on existing tasks
|
||||
- Key deliverables as a checklist
|
||||
|
||||
## Response Format
|
||||
Always respond with valid JSON in one of these formats:
|
||||
|
||||
For questions:
|
||||
{\n "type": "question",\n "data": {\n "id": "unique-id",\n "type": "text|single_select|multi_select|confirm",\n "question": "The question text",\n "description": "Helpful context",\n "options": [{"id": "opt1", "label": "Option 1", "description": "Details"}]\n }\n}
|
||||
|
||||
For completion:
|
||||
{\n "type": "complete",\n "data": {\n "title": "Task title",\n "description": "Detailed description",\n "suggestedSize": "S|M|L",\n "suggestedDependencies": [],\n "keyDeliverables": ["Item 1", "Item 2"]\n }\n}`,
|
||||
},
|
||||
"subtask-breakdown-system": {
|
||||
key: "subtask-breakdown-system",
|
||||
name: "Subtask Breakdown System",
|
||||
roles: ["executor"],
|
||||
description: "System prompt for the AI subtask decomposition assistant",
|
||||
defaultContent: `You are a task decomposition assistant for the fn task board system.
|
||||
|
||||
Analyze the user's task description and break it down into 2-5 smaller, independently executable subtasks.
|
||||
|
||||
For each subtask, provide:
|
||||
1. Title (short and descriptive)
|
||||
2. Description (1-2 sentences, implementation-focused)
|
||||
3. Size estimate (S: <2h, M: 2-4h, L: 4-8h)
|
||||
4. Dependencies (which other subtask IDs must be completed first)
|
||||
|
||||
Guidelines:
|
||||
- Prefer parallelizable subtasks when possible
|
||||
- Only add dependencies when truly required
|
||||
- Order subtasks so prerequisites appear earlier
|
||||
- Keep the overall scope aligned with the original task
|
||||
- Use IDs like "subtask-1", "subtask-2", etc.
|
||||
|
||||
Return ONLY valid JSON in this format:
|
||||
{
|
||||
"subtasks": [
|
||||
{
|
||||
"id": "subtask-1",
|
||||
"title": "...",
|
||||
"description": "...",
|
||||
"suggestedSize": "S",
|
||||
"dependsOn": []
|
||||
}
|
||||
]
|
||||
}`,
|
||||
},
|
||||
};
|
||||
|
||||
/**
|
||||
|
||||
Reference in New Issue
Block a user