mirror of
https://github.com/R0m1k3/xtremflow.git
synced 2026-10-24 07:28:05 +02:00
feat: security overhaul (proxy ssrf fix, streaming sanitization, docker optimization)
This commit is contained in:
Michael committed
1 parent
6d87ada2b8
commit
8df9a37baa
810 files changed
+131090
-151
No files matched your search
@@ -0,0 +1,305 @@
|
||||
---
|
||||
name: 'step-06-structure'
|
||||
description: 'Define project structure, directory organization, and architectural boundaries'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmgd/workflows/3-technical/game-architecture'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-06-structure.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-07-patterns.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/game-architecture.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 6: Project Structure
|
||||
|
||||
**Progress: Step 6 of 9** - Next: Implementation Patterns
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Define the complete project structure including directory organization, file naming conventions, and architectural boundaries. This ensures all AI agents place code consistently.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- NEVER generate content without user input
|
||||
- CRITICAL: Read the complete step file before taking any action
|
||||
- CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- YOU ARE A FACILITATOR, not a content generator
|
||||
- NEVER mention time estimates
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- You are a veteran game architect facilitator
|
||||
- Project structure prevents "where does this go?" confusion
|
||||
- Clear boundaries enable parallel development
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- Structure must be complete, not generic placeholders
|
||||
- Map every major system to a location
|
||||
- Define naming conventions explicitly
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- Show your analysis before taking any action
|
||||
- Present A/P/C menu after structure defined
|
||||
- ONLY proceed when user chooses C (Continue)
|
||||
- Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before loading next step
|
||||
|
||||
## COLLABORATION MENUS (A/P/C):
|
||||
|
||||
- **A (Advanced Elicitation)**: Refine structure organization
|
||||
- **P (Party Mode)**: Get perspectives on layout
|
||||
- **C (Continue)**: Confirm structure and proceed
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Determine Organization Pattern
|
||||
|
||||
"Let's define how your project will be organized.
|
||||
|
||||
**Organization Patterns:**
|
||||
|
||||
| Pattern | Description | Best For |
|
||||
| ----------------- | -------------------------------- | ------------- |
|
||||
| **By Feature** | All related files together | Feature teams |
|
||||
| **By Type** | Scripts, assets, scenes separate | Traditional |
|
||||
| **Hybrid** | Types at top, features within | Balanced |
|
||||
| **Domain-Driven** | By game domain/system | Complex games |
|
||||
|
||||
**Engine Conventions:**
|
||||
|
||||
- {{engine}} typically uses: {{engine_convention}}
|
||||
|
||||
What organization pattern do you prefer?"
|
||||
|
||||
### 2. Define Root Structure
|
||||
|
||||
"Based on {{selected_pattern}}, let's define your root structure.
|
||||
|
||||
**For {{engine}}, typical root looks like:**
|
||||
|
||||
```
|
||||
{{project_name}}/
|
||||
├── {{source_folder}}/ # Game source code
|
||||
├── {{assets_folder}}/ # Art, audio, data
|
||||
├── {{scenes_folder}}/ # Scene/level files
|
||||
├── {{tests_folder}}/ # Test files
|
||||
├── {{docs_folder}}/ # Documentation
|
||||
└── {{config_files}} # Project config
|
||||
```
|
||||
|
||||
Does this work, or would you like to adjust?"
|
||||
|
||||
### 3. Detail Source Structure
|
||||
|
||||
"Now let's detail the source code organization.
|
||||
|
||||
**Based on your systems:**
|
||||
{{list_of_systems_from_context}}
|
||||
|
||||
**Proposed structure:**
|
||||
|
||||
```
|
||||
{{source_folder}}/
|
||||
├── core/ # Core systems (singletons, managers)
|
||||
│ ├── {{core_systems}}
|
||||
├── gameplay/ # Gameplay mechanics
|
||||
│ ├── {{gameplay_systems}}
|
||||
├── ui/ # User interface
|
||||
│ ├── {{ui_organization}}
|
||||
├── utils/ # Utilities and helpers
|
||||
│ ├── {{util_types}}
|
||||
└── data/ # Data structures and models
|
||||
└── {{data_types}}
|
||||
```
|
||||
|
||||
What adjustments would you make?"
|
||||
|
||||
### 4. Define Asset Structure
|
||||
|
||||
"Let's organize your assets.
|
||||
|
||||
**Asset Categories:**
|
||||
|
||||
- Art (sprites, textures, models)
|
||||
- Audio (music, sfx, voice)
|
||||
- Data (configurations, levels)
|
||||
- UI (interface assets)
|
||||
|
||||
**Proposed asset structure:**
|
||||
|
||||
```
|
||||
{{assets_folder}}/
|
||||
├── art/
|
||||
│ ├── {{art_categories}}
|
||||
├── audio/
|
||||
│ ├── music/
|
||||
│ ├── sfx/
|
||||
│ └── {{audio_categories}}
|
||||
├── data/
|
||||
│ └── {{data_file_types}}
|
||||
└── ui/
|
||||
└── {{ui_asset_types}}
|
||||
```
|
||||
|
||||
How should assets be organized?"
|
||||
|
||||
### 5. Map Systems to Locations
|
||||
|
||||
"Let's map each major system to its location.
|
||||
|
||||
| System | Location | Notes |
|
||||
| ------ | -------- | ----- |
|
||||
|
||||
{{system_location_mapping}}
|
||||
|
||||
Does this mapping make sense for your project?"
|
||||
|
||||
### 6. Define Naming Conventions
|
||||
|
||||
"Finally, let's establish naming conventions.
|
||||
|
||||
**Files:**
|
||||
|
||||
- Scripts: {{script_naming}} (e.g., PlayerController, enemy_spawner)
|
||||
- Scenes: {{scene_naming}} (e.g., Level01, main_menu)
|
||||
- Assets: {{asset_naming}} (e.g., player_idle, btn_play)
|
||||
|
||||
**Code Elements:**
|
||||
|
||||
- Classes: {{class_naming}} (e.g., PascalCase)
|
||||
- Functions: {{function_naming}} (e.g., snake_case, camelCase)
|
||||
- Variables: {{variable_naming}}
|
||||
- Constants: {{constant_naming}} (e.g., UPPER_SNAKE)
|
||||
|
||||
**Game-Specific:**
|
||||
|
||||
- Prefabs/Scenes: {{prefab_naming}}
|
||||
- Animation clips: {{animation_naming}}
|
||||
- Event names: {{event_naming}}
|
||||
|
||||
What are your naming preferences?"
|
||||
|
||||
### 7. Generate Structure Section
|
||||
|
||||
Based on the conversation, prepare the content:
|
||||
|
||||
```markdown
|
||||
## Project Structure
|
||||
|
||||
### Organization Pattern
|
||||
|
||||
**Pattern:** {{organization_pattern}}
|
||||
|
||||
**Rationale:** {{why_this_pattern}}
|
||||
|
||||
### Directory Structure
|
||||
```
|
||||
|
||||
{{project_name}}/
|
||||
{{complete_directory_tree}}
|
||||
|
||||
```
|
||||
|
||||
### System Location Mapping
|
||||
|
||||
| System | Location | Responsibility |
|
||||
| ------ | -------- | -------------- |
|
||||
{{system_mapping_table}}
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
#### Files
|
||||
{{file_naming_rules}}
|
||||
|
||||
#### Code Elements
|
||||
| Element | Convention | Example |
|
||||
| ------- | ---------- | ------- |
|
||||
{{code_naming_table}}
|
||||
|
||||
#### Game Assets
|
||||
{{asset_naming_rules}}
|
||||
|
||||
### Architectural Boundaries
|
||||
|
||||
{{boundary_rules}}
|
||||
```
|
||||
|
||||
### 8. Present Content and Menu
|
||||
|
||||
Show the generated content to the user and present:
|
||||
|
||||
"I've defined the complete project structure.
|
||||
|
||||
**Here's what I'll add to the document:**
|
||||
|
||||
[Show the complete markdown content from step 7]
|
||||
|
||||
**Validation Check:**
|
||||
|
||||
- Can every system find its home?
|
||||
- Are naming conventions clear and consistent?
|
||||
- Will AI agents know exactly where to place new code?
|
||||
|
||||
**Select an Option:**
|
||||
[A] Advanced Elicitation - Refine structure organization
|
||||
[P] Party Mode - Get perspectives on layout
|
||||
[C] Continue - Save this and move to Implementation Patterns (Step 7 of 9)"
|
||||
|
||||
### 9. Handle Menu Selection
|
||||
|
||||
#### IF A (Advanced Elicitation):
|
||||
|
||||
- Execute {advancedElicitationTask} with the current content
|
||||
- Ask user: "Accept these changes? (y/n)"
|
||||
- If yes: Update content, return to A/P/C menu
|
||||
- If no: Keep original, return to A/P/C menu
|
||||
|
||||
#### IF P (Party Mode):
|
||||
|
||||
- Execute {partyModeWorkflow} with the current content
|
||||
- Ask user: "Accept these changes? (y/n)"
|
||||
- If yes: Update content, return to A/P/C menu
|
||||
- If no: Keep original, return to A/P/C menu
|
||||
|
||||
#### IF C (Continue):
|
||||
|
||||
- Append the final content to `{outputFile}`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6]`
|
||||
- Load `{nextStepFile}`
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [structure content saved with frontmatter updated], will you then load and read fully `{nextStepFile}`.
|
||||
|
||||
---
|
||||
|
||||
## SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### SUCCESS:
|
||||
|
||||
- Complete directory structure defined
|
||||
- Every system mapped to location
|
||||
- Naming conventions explicit and consistent
|
||||
- No placeholder or generic structures
|
||||
- A/P/C menu presented and handled correctly
|
||||
- Frontmatter updated with stepsCompleted: [1, 2, 3, 4, 5, 6]
|
||||
|
||||
### SYSTEM FAILURE:
|
||||
|
||||
- Generic structure with placeholders
|
||||
- Systems without clear locations
|
||||
- Vague naming conventions
|
||||
- Not presenting A/P/C menu after structure
|
||||
- Proceeding without user selecting 'C'
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
Reference in new issue
Block a user